Subject: Re: [PATCH 1/9] Define a structure for object IDs.

From: David Kastrup <[email-masked]>
Date: Mon, 05 May 2014 11:50:11 +0200

Andreas Schwab <[email-masked]> writes:

> David Kastrup <[email-masked]> writes:
>
>> It does not as far as I can see guarantee that a pointer to something
>> of the same type of its first member can be converted to a pointer to
>> a struct even if the struct only contains a member of such type.
>
> This sentence doesn't make any sense.

I disagree.

> If you have an object of struct type

Your premise is _not_ assumed in my statement.  My premise was "a
pointer to something of the same type of [the struct's] first member".
That does quite explicitly _not_ state that an object of struct type is
in existence.

> then any pointer to the first member of the object can only be a
> pointer to the one and same object.

The case we are talking about is basically passing a pointer to some
actual bonafide toplevel unsigned char [20] object to a routine that
expects a pointer to a struct _only_ containing one such
unsigned char [20] element.

This is the situation we have to deal with if a caller has not been
converted to using such a struct, but the called function does.

More seriously, this is the situation we have to deal with when our SHA1
is actually embedded in some header or whatever else that is actually
available only inside of a larger byte buffer.

In that case, the standard does not permit us converting the address
where that SHA1 is into a pointer to struct.  It may well be that this
will fall under the "let's ignore the standard and write for "sensible"
compilers/architectures" dictum, but if it doesn't, it might be
necessary to first copy the data to a struct before passing it to
routines expecting a pointer to struct.

-- 
David Kastrup