Velocity Reviews > Structure byte padding rule

Tim Rentsch
Guest
Posts: n/a

 03-11-2011
Keith Thompson <(E-Mail Removed)> writes:

> Ben Bacarisse <(E-Mail Removed)> writes:
>> sandeep <(E-Mail Removed)> writes:
>>
>>> Eric Sosman writes:

>> <snip>
>>>> struct s { char x; double y; char z; };

>> <snip>
>>>> printf ("struct s takes %d bytes\n", (int)sizeof(struct s));
>>> printf ("x
>>>> starts %d bytes in\n", (int)offsetof(struct s, x)); printf ("y
>>> starts
>>>> %d bytes in\n", (int)offsetof(struct s, y)); printf ("z starts %d
>>> bytes
>>>> in\n", (int)offsetof(struct s, z));
>>>
>>> Unfortunately though, this code will invoke an undefined behavior on an
>>> implementation where sizeof(struct s) is bigger than INTMAX.

>>
>> It's not undefined behaviour -- it's implementation-defined.

> [...]
>
> An overflowing conversion to a signed type [...snip...]

Nit: an out-of-range conversion. "Overflow", as used in
the Standard, is something else (admittedly similar but
still something else).

Tim Rentsch
Guest
Posts: n/a

 03-11-2011
Ben Bacarisse <(E-Mail Removed)> writes:

> Keith Thompson <(E-Mail Removed)> writes:
>
>> Ben Bacarisse <(E-Mail Removed)> writes:
>>> sandeep <(E-Mail Removed)> writes:
>>>
>>>> Eric Sosman writes:
>>> <snip>
>>>>> struct s { char x; double y; char z; };
>>> <snip>
>>>>> printf ("struct s takes %d bytes\n", (int)sizeof(struct s));
>>>> printf ("x
>>>>> starts %d bytes in\n", (int)offsetof(struct s, x)); printf ("y
>>>> starts
>>>>> %d bytes in\n", (int)offsetof(struct s, y)); printf ("z starts %d
>>>> bytes
>>>>> in\n", (int)offsetof(struct s, z));
>>>>
>>>> Unfortunately though, this code will invoke an undefined behavior on an
>>>> implementation where sizeof(struct s) is bigger than INTMAX.
>>>
>>> It's not undefined behaviour -- it's implementation-defined.

>> [...]
>>
>> An overflowing conversion to a signed type either yields an
>> implementation-defined result or raises an implementation-defined signal
>> (C99 6.3.1.3p3). The consequences of raising an implementation-defined
>> signal are (at least potentially) undefined.

>
> I don't see how except as a rather extreme reading the standard.
> [snip elaboration]

Because, for example, an implementation can choose to specify
the behavior of the default signal handler by giving a
function body that would exhibit undefined behavior in some
code paths under some conditions (such as trying to convert
the bit pattern corresponding to negative zero on a machine
that uses ones complement but doesn't support negative
zeroes).