Hrrmmm shouldn't those lines be...
rra at stanford.edu
Fri Sep 8 01:44:41 UTC 2000
Rick Irving <rirving at onecall.net> writes:
> Placing an ampersand in front of an array, even if it is an element of
> the structure.....
It really is entirely defined behavior. ISO C99 section 126.96.36.199:
1 The operand of the unary & operator shall be either a function
designator, the result of a  or unary * operator, or an lvalue that
designates an object that is not a bit-field and is not declared with
the register storage-class specifier.
1 An lvalue is an expression with an object type or an incomplete type
other than void;
so given that an array is an object which is neither a bit-field nor
declared with a register storage-class specifier, taking its address is a
fully defined operation. The result is a pointer to "array of X objects
of type Y", which is different than the pointer value that the array
degrades into ("pointer to type Y"), but which is still a well-defined
pointer value pointing to the beginning of the array. Then, per section
2 The memcmp function compares the first n characters of the object
pointed to by s1 to the first n characters of the object pointed to by
so those pointers are interpreted as char * pointers, which per the
standard are permitted to access any object.
> Hrrm. I think this logic may not lint clean...
> char array;
> Now, I can memcpy ( array, target, size), or, I can memcpy (
> &array, target, size ).
> According to my tired old K&R background, number 2 is wrong..
> err...sloppy, in C.
They're defined by the standard as being entirely equivalent in this
context, and I'm pretty sure that even K&R would have treated them as
> If you want to use the second, in the manner you suggest, I might
> memcpy ( &array, target, size ). Which is great if the array
> -isn't- an array of chars.
"&array" is completely equivalent to "array" when used as an argument
to a function, yes.
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the inn-workers