[This rather technical language-specific discussion is, strictly speaking,
off-topic for comp.programming; followups set to comp.lang.c, although I
admit it might be a bit late now.]
Quote:
<snip>
>> Clearly arrays
>> are not pointers,
> No, the one is a simple element, the other is a sequence of elements.
>> and an array variable is not a pointer variable.
> No, that is *not* the case -- the one is a special instance of the other.
Not so. Now, even if it /were/ so, that would not mean that "array variable"
is a synonym for "pointer".
Quote:
>> Therefore, "array variable" is not a synonym for "pointer".
> No, but that's because you're crossing terms from the previous two
> sentences.
Quote:
>>> It says literally: "By definition, the value of a variable or expression
>>> of type array is the address of element zero of the array".
>>> By comparison, a pointer is defined (page 93) as "a variable that
>>> contains the address of a variable".
>> Don't skip over the words "value of". They are /so/ important.
> By the same token, don't skip the word "contains" -- /equally/ important
> in a language so wonderfully ambiguous as English.
no real import to this discussion, though (IMHO).
Quote:
>>> ... THIS is not the case. A typing system that defines subtypes or
>>> special cases of types will, in general, allow operations on types to
>>> differentiate to specific types. Your example of sizeof is an example of
>>> exactly that.
>> No, it's an example of arrays not being the same as pointers.
> I'm sure you would like it to be
language simply doesn't work like that.
Quote:
> -- however, that you handle a special
> instance of a type differently through subtype differentiation doesn't
> mean that it is no longer a subtype.
Subtypes are neither here nor there. All I am arguing is that arrays are not
pointers, and pointers are not arrays.
Quote:
>> From the point of view of a programmer trying to make his way in a cruel
>> and difficult world, the kindest thing to do is to tell him the truth
>> about how his language works, not about how you'd like it to work if it
>> weren't for this irritating thing called an international standard.
> Which is exactly what I'm doing -- take a look at what a C compiler (any C
> compiler) generates for your source code.
Quote:
> That aside, if you want to
> understand the semantics of a language, I find that in general it helps
> not to make things more difficult than they are. Such as by way of
> introducing a difference where there is none.
Sure, but there /is/ a difference in this case, and an important one.
<snip: my example of erroneous code based on confusion between arrays and
pointers>
Quote:
>> I /have/ seen code like that, and it is caused by people thinking arrays
>> and pointers are the same thing. If you are aware that they are not, you
>> are not even remotely likely to make this particular mistake.
> Well, I can't disagree with that -- albeit with the nuance that the cause
> of the problem is a general misunderstanding of the fact that not every
> instance of a general case is an instance of the special case and that
> such a misunderstanding is hardly limited to pointers and arrays in C. But
> the principle remains the same, without changing the validity of the view
> or the point.
not in C.
<snip>
--
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.*-*-*.com/ ~scs/C-faq/top.html
K&R answers, C books, etc: http://www.*-*-*.com/
C Question - pointer & address-operator