Hrrmmm shouldn't those lines be...

Richard Irving rirving at
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> 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
> 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
> 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,
rather than
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
>   s2.
> 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
and back,
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[9999];
> >    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
> such.

   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[0], target, size ).   Which is great if the array
> > -isn't- an array of chars.
> "&array[0]" 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[0], and that is -not-
always true,
   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
running for
   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             <>

More information about the inn-workers mailing list