extern char *foo vs. extern char foo[]

diamond@tkovoa diamond at tkou02.enet.dec.com
Wed May 30 17:59:31 AEST 1990


In article <1990May30.001219.23564 at uunet!unhd> rg at unhd.unh.edu.UUCP (Roger Gonzalez ) writes:
>A little history: I know C inside and out, and don't need any "I think"s.
This is a lie.
flame = m * pow(c, 2.0);

>According to K&R, there should be no difference between the two extern
>defs in my subject header.  In fact, the second form (char foo[]) should
>get translated into the first.
You mean declarations, not defs.  Let's assume the correction.  Now:
Where does K&R say that a declaration of anything other than a parameter
gets translated in this manner?

>Unfortunately, it doesn't.
Bingo!  This time, you don't need an "I think".  Indeed, for starters,
an array of 100 characters has size 100, while a pointer to a character
has the size that a pointer-to-char has.  Therefore the two external
objects cannot even begin to be the same.

>I stopped the output at the assembler stage, and
>mov hello, (sp%)
>mov &hello, (sp%)
>Aha!  Zees eez very wrong!
No.  It is very right.

>This is the same output I got on 3 different machines, running Unisoft
>and Green Hills compilers.  So.  Why are my compilers so stupid?
Usually it's because they do what you tell them.

>Do others behave the same way,
Mostly.  Many compilers have bugs, but most of them will get this right.

>or am I just unfortunate enough to have lousy software?
I guess so, if your brain is soft.

>If this is more widespread, WHY?  Is this a manifestation of some other
>C rule that takes precedence over what the "proper" behavior?
Well, there is a C rule that says that a pointer is a pointer.  I don't
think this is ever overridden.
Another C rule says that an array is an array.  This is overridden for
declarations of formal parameters, and for rvalues in executable
expressions, neither of which is the case in your example.
Yeah, I guess C rules take precedence over your imagination.
Common sense also takes precedence over your imagination.
"Proper" behavior is to ignore your coding, ignore the language you're
programming in, and just guess what results you wanted, eh?

m = 0; exit(UINT_MAX);
-- 
Norman Diamond, Nihon DEC     diamond at tkou02.enet.dec.com
Proposed group comp.networks.load-reduction:  send your "yes" vote to /dev/null.



More information about the Comp.lang.c mailing list