Subject: Re: CMSG_* problems
To: None <tech-userlevel@NetBSD.org, tech-kern@NetBSD.org>
From: Peter Seebach <seebs@seebs.net>
List: tech-userlevel
Date: 02/12/2007 18:09:01
In message <4A6C0FF4-2BD3-4E11-8469-2910ABF121D2@shagadelic.org>, Jason Thorpe writes:
>
>On Feb 12, 2007, at 3:27 PM, der Mouse wrote:
>
>> Will be able to contain a pointer, sure.  But not necessarily, will be
>> at least as strictly aligned as a pointer.
>
>You're completely wrong on this one.  intmax_t is by definition at  
>least as large and at least as alignment-strict as intptr_t, which in  
>turn is by definition at least as large and at least as alignment- 
>strict as a pointer.

"As large as" seems a fair bet, but neither of these is directly guaranteed.
It is guaranteed that any valid pointer to void can be converted to
intptr_t, then converted back, and the result will compare equal to the
original pointer.  Imagine, if you will, a hypothetical system implemented
on one of the many hybrid 32/64-bit environments, in which architectural
constraints guarantee that there will never be more than 32 bits of addressable
space, even though the pointer type is natively 64 bits.  In such a system,
intptr_t could be legitimately implemented as a 4-byte unsigned long,
with the conversion to and from stripping the top 32 0 bits, or adding
them back, because the implementor knows that those bits never have non-zero
values.

Furthermore, it is not at all guaranteed that alignment requirements
are a direct function of size; while I think there's no way to build
a conforming implementation where alignment requirements for a type
are greater than its size, it's quite possible for them to be smaller.
It would be quite thinkable for an implementation to allow only size-aligned
pointers, while allowing byte-aligned integers of any size, so intptr_t
might have looser alignment requirements than pointers.

However, the assumption that an object "at least as large as" another object
has alignment requirements at least as strict is not safe.  If intmax_t is
a non-native type (and it seems likely that it might be), the implementation
might be very carefully generic and have no alignment requirements, while
intptr_t might be a native type which has at least some alignment requirements.

-s