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

From: David Kastrup <dak@gnu.org>
Date: May 5, 2014, 09:50 UTC
Message-ID: <87d2fstuzw.fsf@fencepost.gnu.org>
In-Reply-To: <87vbtk60lh.fsf@igel.home>

Andreas Schwab <schwab@linux-m68k.org> writes:

Show 7 quoted lines

> David Kastrup <dak@gnu.org> 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