[IRCServices Coding] GCC3

[Trevor Talbot]

On Monday, February 25, 2002, at 09:48  PM, Andrew Church wrote:

>> Reordering is not permitted by the ANSI/ISO C standards.
>
>      That's what I thought, but a whole bunch of people seemed to think 
> GCC
> 3.0 was doing just that.

It occurs to me that this has been talked about as a somewhat-useful
optimization.  The idea is to reorder struct members for optimal padding.
But even if gcc did adopt this as an extension (I don't know if it does 
or
not), it would have to be disabled by default, as several things (such as
ANSI offsetof()) would break.

>      Again, that's what I thought--compilers aren't supposed to pad more
> than the largest type in the structure, and between structure members 
> only
> enough to align the next member to a multiple of its size.  I'm pretty 
> sure
> this is defined somewhere, and if not then it should be (see below).
>
>> Partly for this reason, mapping structs onto arbitrary data in
>> memory results in undefined behavior.
>
>      It shouldn't, and if it did things would break all over the place.
> Suppose you have two compilers, one of which is used to compile a 
> program,
> and the other of which is used to compile a library used by the program.
> Now suppose the program passes a pointer to a structure (say, a FILE *) 
> to
> the library.  If the two compilers use different algorithms to pad
> structure members, guess what happens?  Boom.

Actually, I was referring to things such as:

     struct tag {
         char type;
         uint_32 value;
     } *s;

     char map[32];

     /* load map with some data */

     s = (struct tag *)map;

But your point about compilers is a valid one; I don't know about
POSIX (as someone else commented), but in general compilers adopt
the same alignment scheme for a particular architecture.  After all,
the architecture is what requires certain alignments anyway :)

-- Quension