* Rich Felker:
On Thu, Dec 13, 2018 at 05:04:59PM +0100, Florian Weimer wrote:
quoted
* Rich Felker:
quoted
quoted
If the compiler can handle the zeroing, that would be great, though not
sure how (some __attribute__((zero)) which generates a type constructor
for such structure; it kind of departs from what the C language offers).
The compiler fundamentally can't. At the very least it would require
effective type tracking, which requires shadow memory and is even more
controversial than -fstrict-aliasing (because in a sense it's a
stronger version thereof).
It's possible to do it with the right types. See _Bool on 32-bit Darwin
PowerPC for an example, which is four bytes instead of the usual one.
Similarly, we could have integer types with trap representations.
Whether it is a good idea is a different matter, but the amount of
compiler magic required is actually limited.
If you do this you just have LP64 with value range restricted to
32-bit.
You have to a type different from long int for the relevant struct
fields. This type would have zero padding.
Florian
On Fri, Dec 14, 2018 at 12:42:34PM +0100, Florian Weimer wrote:
* Rich Felker:
quoted
On Thu, Dec 13, 2018 at 05:04:59PM +0100, Florian Weimer wrote:
quoted
* Rich Felker:
quoted
quoted
If the compiler can handle the zeroing, that would be great, though not
sure how (some __attribute__((zero)) which generates a type constructor
for such structure; it kind of departs from what the C language offers).
The compiler fundamentally can't. At the very least it would require
effective type tracking, which requires shadow memory and is even more
controversial than -fstrict-aliasing (because in a sense it's a
stronger version thereof).
It's possible to do it with the right types. See _Bool on 32-bit Darwin
PowerPC for an example, which is four bytes instead of the usual one.
Similarly, we could have integer types with trap representations.
Whether it is a good idea is a different matter, but the amount of
compiler magic required is actually limited.
If you do this you just have LP64 with value range restricted to
32-bit.
You have to a type different from long int for the relevant struct
fields. This type would have zero padding.
Just upthread (Message-ID: [off-list ref])
I explained why this does not work:
quoted
quoted
If on the other hand you tried to make just some pointers "wide
pointers", you'd also be completely breaking the specified API
contracts of standard interfaces. For example in struct iovec's
iov_base, &foo->iov_base is no longer a valid pointer to an object of
type void* that you can pass to interfaces expecting void**. Sloppy
misunderstandings like what you're making now are exactly why x32 is
already broken and buggy (&foo->tv_nsec already has wrong type for
struct timespec foo).
Rich