which is the better path

[Dan Pop]

For the record, I can't parse *that*. Unless you were trying your
hand at humor, which is usually lost on Dan anyway.

On the contrary, *successful* attempts at humour are seldom lost on me.
It's Joona that regularly misses them.

Dan

 

[Joona I Palaste]

On the contrary, *successful* attempts at humour are seldom lost on me.
It's Joona that regularly misses them.

Dan is as fond of calling me humourless as he is of calling Mark
McIntyre an idiot. It's those mannerisms of his that makes him amazingly
funny. As long as you don't take them seriously, that is. Dan Pop's
advice about C, though - THAT should be taken seriously.

 

[CBFalconer]

.... snip ...

Dan is as fond of calling me humourless as he is of calling Mark
McIntyre an idiot. It's those mannerisms of his that makes him
amazingly funny. As long as you don't take them seriously, that
is. Dan Pop's advice about C, though - THAT should be taken
seriously.

In the last week or so something seems to have driven him from his
normal jolly carefree self, and he has become especially intent on
picking, shall we say, nits.

 

[Martin Dickopp]

(e-mail address removed) (Dan Pop) writes:


(e-mail address removed) (Dan Pop) writes:


Few expressions yield an array type. Among them are the (possible
^^^^^^^^^^^^^
parenthesesed) identifier referring to the array,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Huh?

char array[3];
char *p = array;

Anything wrong with this snippet that, according to you, assigns an
array to a pointer?

Huh? Where did I say that this assigns an array to a pointer?

In the underlined text above. In the absence of *any* explicitly
mentioned exception, it says that my code assigns an array to a
pointer.

The absence of explicitly mentioned exceptions is to interpreted as
"unless a conversion rule applies".

But, since a conversion rule applies *by default* here, your statement
is still patently false.

The conversion rule only applies if the expression is not the operand of
the `sizeof' or unary & operator.

I.e. in the general case. Hence, it is the default.

Whether or not it applies by default *here* (by which you mean your
example above, I presume) is not relevant, since I never claimed that
it doesn't apply in your example.

You never mentioned it *at all*, which means, by implication, that it
never happens.

Your implication is wrong. There are millions of things which I never
mention, but which still happen.

My point is that the *only* possible inference from your answer is the
one I've made. Therefore, your answer is incorrect.

I've already explained why your inference is incorrect, but feel free
to believe what you must.

 

[Dan Pop]

Dan is as fond of calling me humourless as he is of calling Mark
McIntyre an idiot. It's those mannerisms of his that makes him amazingly
funny.

Those "mannerisms" are based on reading your (and Mark McIntyre's) posts
ever since you joined the newsgroup. And they will change, as soon as I
detect a systematic change in the input.

Dan

 

[Dan Pop]

(e-mail address removed) (Dan Pop) writes:


(e-mail address removed) (Dan Pop) writes:


(e-mail address removed) (Dan Pop) writes:


Few expressions yield an array type. Among them are the (possible
^^^^^^^^^^^^^
parenthesesed) identifier referring to the array,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Huh?

char array[3];
char *p = array;

Anything wrong with this snippet that, according to you, assigns an
array to a pointer?

Huh? Where did I say that this assigns an array to a pointer?

In the underlined text above. In the absence of *any* explicitly
mentioned exception, it says that my code assigns an array to a
pointer.

The absence of explicitly mentioned exceptions is to interpreted as
"unless a conversion rule applies".

But, since a conversion rule applies *by default* here, your statement
is still patently false.

The conversion rule only applies if the expression is not the operand of
the `sizeof' or unary & operator.

I.e. in the general case. Hence, it is the default.

Whether or not it applies by default *here* (by which you mean your
example above, I presume) is not relevant, since I never claimed that
it doesn't apply in your example.

You never mentioned it *at all*, which means, by implication, that it
never happens.

Your implication is wrong. There are millions of things which I never
mention, but which still happen.

But they're irrelevant to our issue. The point is that your statement
is wrong by not mentioning the things that are highly relevant to it.

It's like saying "it rains every day" and then trying to save your ass
by claiming that "unless it doesn't" also applies to it.

Dan

 

[Martin Dickopp]

(e-mail address removed) (Dan Pop) writes:


(e-mail address removed) (Dan Pop) writes:


(e-mail address removed) (Dan Pop) writes:


Few expressions yield an array type. Among them are the (possible
^^^^^^^^^^^^^
parenthesesed) identifier referring to the array,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Huh?

char array[3];
char *p = array;

Anything wrong with this snippet that, according to you, assigns an
array to a pointer?

Huh? Where did I say that this assigns an array to a pointer?

In the underlined text above. In the absence of *any* explicitly
mentioned exception, it says that my code assigns an array to a
pointer.

The absence of explicitly mentioned exceptions is to interpreted as
"unless a conversion rule applies".

But, since a conversion rule applies *by default* here, your statement
is still patently false.

The conversion rule only applies if the expression is not the operand of
the `sizeof' or unary & operator.

I.e. in the general case. Hence, it is the default.

Whether or not it applies by default *here* (by which you mean your
example above, I presume) is not relevant, since I never claimed that
it doesn't apply in your example.

You never mentioned it *at all*, which means, by implication, that it
never happens.

Your implication is wrong. There are millions of things which I never
mention, but which still happen.

But they're irrelevant to our issue. The point is that your statement
is wrong by not mentioning the things that are highly relevant to it.

It's like saying "it rains every day" and then trying to save your ass
by claiming that "unless it doesn't" also applies to it.

No, that analogy is faulty. It would be a good analogy if I had said
"expressions of array type retain their array type in /every/ context",
and then later claimed that there are exceptions to "every context".
But that's not what I actually said.

 

[Dan Pop]

(e-mail address removed) (Dan Pop) writes:


(e-mail address removed) (Dan Pop) writes:


(e-mail address removed) (Dan Pop) writes:


(e-mail address removed) (Dan Pop) writes:


Few expressions yield an array type. Among them are the (possible
^^^^^^^^^^^^^
parenthesesed) identifier referring to the array,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Huh?

char array[3];
char *p = array;

Anything wrong with this snippet that, according to you, assigns an
array to a pointer?

Huh? Where did I say that this assigns an array to a pointer?

In the underlined text above. In the absence of *any* explicitly
mentioned exception, it says that my code assigns an array to a
pointer.

The absence of explicitly mentioned exceptions is to interpreted as
"unless a conversion rule applies".

But, since a conversion rule applies *by default* here, your statement
is still patently false.

The conversion rule only applies if the expression is not the operand of
the `sizeof' or unary & operator.

I.e. in the general case. Hence, it is the default.

Whether or not it applies by default *here* (by which you mean your
example above, I presume) is not relevant, since I never claimed that
it doesn't apply in your example.

You never mentioned it *at all*, which means, by implication, that it
never happens.

Your implication is wrong. There are millions of things which I never
mention, but which still happen.

But they're irrelevant to our issue. The point is that your statement
is wrong by not mentioning the things that are highly relevant to it.

It's like saying "it rains every day" and then trying to save your ass
by claiming that "unless it doesn't" also applies to it.

No, that analogy is faulty. It would be a good analogy if I had said
"expressions of array type retain their array type in /every/ context",
and then later claimed that there are exceptions to "every context".
But that's not what I actually said.

This is what you actually implied, by not mentioning the possibility of
exceptions.

Dan

 

[Martin Dickopp]

No, that analogy is faulty. It would be a good analogy if I had said
"expressions of array type retain their array type in /every/ context",
and then later claimed that there are exceptions to "every context".
But that's not what I actually said.

This is what you actually implied, by not mentioning the possibility of
exceptions.

Given

struct {
char a [3];
} foo;

`foo.a' has array type.

with the statement

Nope. The type of this expression is pointer to char.

You didn't mention any exceptions. Does that mean that the expression
`foo.a' has type pointer-to-char even when it is operand to the `sizeof'
operator, or does your "exceptions which are not mentioned don't exist"
rule only apply to me, and not to you?

Martin

 

[Dan Pop]

(e-mail address removed) (Dan Pop) writes:

It's like saying "it rains every day" and then trying to save your ass
by claiming that "unless it doesn't" also applies to it.

No, that analogy is faulty. It would be a good analogy if I had said
"expressions of array type retain their array type in /every/ context",
and then later claimed that there are exceptions to "every context".
But that's not what I actually said.

This is what you actually implied, by not mentioning the possibility of
exceptions.

Given

struct {
char a [3];
} foo;

`foo.a' has array type.

with the statement

Nope. The type of this expression is pointer to char.

You didn't mention any exceptions.

There are NO exceptions, as long as we are talking about this expression.

Does that mean that the expression
`foo.a' has type pointer-to-char even when it is operand to the `sizeof'
operator,

In this case, it is NOT an expression, it is a subexpression in a larger
expression.

or does your "exceptions which are not mentioned don't exist"
rule only apply to me, and not to you?

It is a universal rule, of course.

Dan

 

[Martin Dickopp]

(e-mail address removed) (Dan Pop) writes:

It's like saying "it rains every day" and then trying to save your ass
by claiming that "unless it doesn't" also applies to it.

No, that analogy is faulty. It would be a good analogy if I had said
"expressions of array type retain their array type in /every/ context",
and then later claimed that there are exceptions to "every context".
But that's not what I actually said.

This is what you actually implied, by not mentioning the possibility of
exceptions.

Given

struct {
char a [3];
} foo;

`foo.a' has array type.

with the statement

Nope. The type of this expression is pointer to char.

You didn't mention any exceptions.

There are NO exceptions, as long as we are talking about this expression.

Does that mean that the expression
`foo.a' has type pointer-to-char even when it is operand to the `sizeof'
operator,

In this case, it is NOT an expression, it is a subexpression in a larger
expression.

Are you saying that a subexpression is not an expression? `foo.a'
seems to fulfill the criteria of 6.5#1 even when it is part of a
larger expression. And according to the grammar rules, the operand
of the `sizeof' operator is a unary-expression (6.5.3#1), and a
unary-expression is an expression (6.5.N#1, N = 4 to 17).

Martin

 

[Dan Pop]

(e-mail address removed) (Dan Pop) writes:


(e-mail address removed) (Dan Pop) writes:

It's like saying "it rains every day" and then trying to save your ass
by claiming that "unless it doesn't" also applies to it.

No, that analogy is faulty. It would be a good analogy if I had said
"expressions of array type retain their array type in /every/ context",
and then later claimed that there are exceptions to "every context".
But that's not what I actually said.

This is what you actually implied, by not mentioning the possibility of
exceptions.

In <c109ki$6v6$4@sunnews.cern.ch>, you replied to my statement

Given

struct {
char a [3];
} foo;

`foo.a' has array type.

with the statement

Nope. The type of this expression is pointer to char.

You didn't mention any exceptions.

There are NO exceptions, as long as we are talking about this expression.

Does that mean that the expression
`foo.a' has type pointer-to-char even when it is operand to the `sizeof'
operator,

In this case, it is NOT an expression, it is a subexpression in a larger
expression.

Are you saying that a subexpression is not an expression? `foo.a'
seems to fulfill the criteria of 6.5#1 even when it is part of a
larger expression. And according to the grammar rules, the operand
of the `sizeof' operator is a unary-expression (6.5.3#1), and a
unary-expression is an expression (6.5.N#1, N = 4 to 17).

I am saying that, when presented *alone*, foo.a is supposed to be
treated as such (i.e. as a *complete* expression) and not as part of
a larger expression.

Dan

 

[Martin Dickopp]

(e-mail address removed) (Dan Pop) writes:


(e-mail address removed) (Dan Pop) writes:

It's like saying "it rains every day" and then trying to save your ass
by claiming that "unless it doesn't" also applies to it.

No, that analogy is faulty. It would be a good analogy if I had said
"expressions of array type retain their array type in /every/ context",
and then later claimed that there are exceptions to "every context".
But that's not what I actually said.

This is what you actually implied, by not mentioning the possibility of
exceptions.

In <c109ki$6v6$4@sunnews.cern.ch>, you replied to my statement

Given

struct {
char a [3];
} foo;

`foo.a' has array type.

with the statement

Nope. The type of this expression is pointer to char.

You didn't mention any exceptions.

There are NO exceptions, as long as we are talking about this expression.

Does that mean that the expression
`foo.a' has type pointer-to-char even when it is operand to the `sizeof'
operator,

In this case, it is NOT an expression, it is a subexpression in a larger
expression.

Are you saying that a subexpression is not an expression? `foo.a'
seems to fulfill the criteria of 6.5#1 even when it is part of a
larger expression. And according to the grammar rules, the operand
of the `sizeof' operator is a unary-expression (6.5.3#1), and a
unary-expression is an expression (6.5.N#1, N = 4 to 17).

I am saying that, when presented *alone*, foo.a is supposed to be
treated as such (i.e. as a *complete* expression) and not as part of
a larger expression.

No, you said "In this case, it is NOT an expression [...]", not "In this
case, it is NOT a complete expression [...]".

That said, I disagree that an expression which is presented without
context is supposed to be treated as a complete expression. If the
intention is to present a complete expression, it is easy enough to make
that clear, e.g. by turning it into an expression statement. But in the
absence of context, no context can be assumed.

Martin

 

[Dan Pop]

That said, I disagree that an expression which is presented without
context is supposed to be treated as a complete expression.

It is the only meaningful approach, as it is completely impractical to
try to speculate on ALL the possible contexts in which that expression
could be used as a subexpression.

Dan

 

[Martin Dickopp]

It is the only meaningful approach, as it is completely impractical to
try to speculate on ALL the possible contexts in which that expression
could be used as a subexpression.

There was no need to speculate. I was merely enumerating /possible/
expressions with array type, i.e. expressions which have array type in
at least one context. Therefore, it wasn't necessary to consider all
possible contexts.

Martin

 

[Dan Pop]

There was no need to speculate. I was merely enumerating /possible/
expressions with array type, i.e. expressions which have array type in

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

at least one context. Therefore, it wasn't necessary to consider all ^^^^^^^^^^^^^^^^^^^^
possible contexts.

Where did you say that in the post that started this discussion?

Dan

 

[Martin Dickopp]

Where did you say that in the post that started this discussion?

I didn't. But I also didn't explictly talk about all contexts.
Therefore, that omission makes my original statement misleading,
but not wrong.

Martin

 

[Dan Pop]

I didn't. But I also didn't explictly talk about all contexts.
Therefore, that omission makes my original statement misleading,
but not wrong.

Restrictions not explicitly mentioned (or implied by the context) don't
exist. This makes your original statement wrong. Furthermore, your
original statement was true only in *exceptional* cases and wrong in the
rest of the cases.

Compare your original statement with its negation (both are false,
as such) and see which of them correctly covers more cases.

Dan

 

[Martin Dickopp]

Restrictions not explicitly mentioned (or implied by the context)
don't exist.

I still disagree, but if such a rule existed, your reply to my statement

Given

struct {
char a [3];
} foo;

`foo.a' has array type.

Nope. The type of this expression is pointer to char.

would have been wrong, as there is no explictely mentioned or implied
context.

This makes your original statement wrong. Furthermore, your
original statement was true only in *exceptional* cases and wrong in the
rest of the cases.

Compare your original statement with its negation (both are false,
as such) and see which of them correctly covers more cases.

How can my original statement be wrong, true in exceptional cases, and
false at the same time? If it was true, even if only in exceptional
cases, it cannot also be wrong and false.

Martin

 

[Dan Pop]

Restrictions not explicitly mentioned (or implied by the context)
don't exist.

I still disagree, but if such a rule existed, your reply to my statement

Given

struct {
char a [3];
} foo;

`foo.a' has array type.

Nope. The type of this expression is pointer to char.

would have been wrong, as there is no explictely mentioned or implied
context.

The lack of context *implies* a complete expression.

How can my original statement be wrong, true in exceptional cases, and
false at the same time? If it was true, even if only in exceptional
cases, it cannot also be wrong and false.

Of course it can. Consider the statement "it rains". Without aditional
context, it can be both true and false. If we manage to define a default
context, we can establish whether it's true or false. The exceptional
cases (if mentioned), could have established a context in which your
statement was true. In their absence, the statement was false.

Dan