Hrrmmm shouldn't those lines be...

[Richard Irving]

Hello,

   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 6.5.3.2:
> 
> 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 6.3.2.1:
> 
> 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
probably
-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
> 7.21.4.1:

   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
form.
I am not saying it doesn't work, I am saying it is poor form, in
practice.

  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,
IMHO.
   
   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 stanford.edu)             <http://www.eyrie.org/~eagle/>