[IRCServices Coding] GCC3

[Andrew Church]

     Just to clarify, my point is padding shouldn't be put in where it
isn't needed; for example,

struct {
    int8_t a, b, c;
} baz;

should give sizeof(baz) == 3 (and it does in gcc 2.95.3).

  --Andrew Church
    achurch at achurch.org
    http://achurch.org/

>>>      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).
>>Not the largest type in the structure, the largest *type*.
>>Most structures will pad to 32 bits on intel machines.
>>
>>like this:
>>
>>struct {
>>  int8_t byte;
>>  /* inserts 8 or 24 bits of padding here */
>>  int16_t word;
>>  /* inserts 16 bits of padding here */
>>  int32_t dword;
>>  /* no padding here */
>>} something;
>
>     That's missing the point; you put a 32-bit type in there, which of
>course means it will pad to 32 bits.  (And by your argument, it would have
>to pad to at least the size of a double, not just an int32_t.)  What you're
>saying would be something like:
>
>struct {
>    int8_t byte;
>    /* 24 bits of padding */
>    int16_t word;
>    /* 16 bits of padding */
>} foo;  /* size = 64 bits */
>
>which is stupid because you have 32 bits of wasted space, when you could
>just as easily and with no alignment problems (at least on any CPU I know
>of) have done:
>
>struct {
>    int8_t byte;
>    /* 8 bits of padding */
>    int16_t word;
>} bar;  /* size = 32 bits */
>
>  --Andrew Church
>    achurch at achurch.org
>    http://achurch.org/
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding