Re: Number of bits in C99 float types?

jacob navia <jacob@[EMAIL PROTECTED]
> writes:
> Eric Sosman wrote:
>> jacob navia wrote:
>>> Eric Sosman wrote:
[...]
>>>>     If sizeof(long double) * CHAR_BIT == 96 on some system,
>>>> then 96 *is* the number of bits in a long double, not some
>>>> kind of "rounded up" result.  
>>>
>>> No. In the x86 the long double is 10 bytes, but it
>>> is rounded up into 12 (lcc-win) or even 16, just for
>>> alignment reasons.
>>
>>     So, I can safely store a few additional chars in the
>> extra bytes?
>>
>>     union {
>>         long double aligner;
>>         unsigned char buff[16];
>>     } u;
>>     memset (u.buff, 'x', sizeof u.buff);
>>     *(long double*)u.buff = 42.0L;
>>     assert (u.buff[10] == 'x');
>>
>> All happy and hunky-dory, right?
>>
>
> ??? What do you want to prove?
>
> That long doubles are NOT 10 bytes?
>
> Or what?
>
> I do not see the point.

If sizeof(long double) == 12, then long double is 12 bytes, not 10
bytes.  It might be the case that only 10 of those bytes contribute to
the value, and the other two bytes are some sort of padding added by
the compiler.  A long double isn't 10 bytes plus some padding that
isn't part of the long double; it's 12 bytes *including* two bytes of
padding.

Similarly, if this structure:
    struct {
        int i;  /* assume 4 bytes */
        char c; /* 1 byte */
    };
is padded to 8 bytes, then the size of the structure really is 8
bytes; the 3 bytes of padding are part of the structure.

You're making a valid point: that a C long double is based on a
10-byte hardware floating-point format.  But that 10-byte format is
not a C long double; the padded 12-byte data type is a C long double.

-- 
Keith Thompson (The_Other_Keith) <kst-u@[EMAIL PROTECTED]
>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"