Hrrmmm shouldn't those lines be...
rirving at onecall.net
Fri Sep 8 14:33:22 UTC 2000
I don't work in an Ivory tower, and as such,
I have no intention to chase down all possible
documentation to back my perspective.
I don't have the time.
I'll drop my 2 cents, and maybe we can get back to trouble
shooting the actual code....
Russ Allbery wrote:
> 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.
> and 188.8.131.52:
> 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.
Not the issue, Ok, maybe it is the issue... actually, this is
-exactly- the issue, an opening in the specs.
However, in this case, I suspect I may go to someone in IEEE,
or the ACM group, with respect to leaving opening in the specs.
What you say is -true-, it -is- covered by this rule...
However, in practice this is poor form.
As such the ISO specs should be updated to reflect the practice,
the other way around.
> 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
Yup , but without it being a char, or void * object,
the scalar would be off, wouldn't it ? It works, but sloppy.
> 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.
Yes, relying upon a common cast to char works, but it is still poor
I am not saying it doesn't work, I am saying it is poor form, in
There was a time when we flipped unsigned 32bit Ints into pointers
as a common practice. When 64 bit systems came around, we learned the
error of our ways....sloppy.
> > 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
All I can say is I don't think this would have compiled in 89.
At least not without warnings... or errors.
Current True64/Digital compilers treat it as a warning, as is...
(The -reason- I chose the word "undefined", BTW)
* Shrug *
Take it up with Dec, errr... Compaq.
> > If you want to use the second, in the manner you suggest, I might
> > recommend
> > 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.
To a function that cast the pointer to type char, or void, anyway.
But the real question is &array = &array, and that is -not-
do to the differing scalars, correct ?
It works in this case, however, it remains poor form in practice,
Now, if only the current version of this code could stay up and
24 hours... without nursing... I would be more inclined to listen
to these arguments.
In the meantime, we stand around debating an Ivory tower point,
when we probably should be cleaning up code , eh ?
> Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the inn-workers