Bitfield subtlety

[Marc Glisse]

On Wed, 28 Mar 2018, Torbjörn Granlund wrote:

> I am playing with a GMP version which allows greater mpz numbers than
> what is currently handled.  The idea is to combine the _mp_size and
> _mp_alloc fields such that _mp_size becomes 40 bits while _mp_alloc
> becomes a custom float.
>
> I ran into some problems with C and C++ when it comes to bit fields.
>
> In C++, a bit field whose base type is not explicitly signed or unsigned
> gets undefined signedness.  It would be desirable to use stdint.h's
> int64_t, but while that is signed, it is not guaranteed to be explicitly
> so.

ISTR that this has changed (maybe only recently for C++20 though).

> In C, at least old C, allows just (signed or unsigned ) int as base
> types.  I.e., long is not allowed, and thus int64_t is also not allowed.
>
>
> Does anybody on this list know if C99 is more tolerant wrt base type? If
> so, will implicity signed basetypes result in signed bit fields (unlike
> C++)?

C11 still seems to limit bit-fields quite strictly:
"A bit-field shall have a type that is a qualified or unqualified version 
of _Bool, signed int, unsigned int, or some other implementation-defined 
type."


In C++, there is also the strange behavior that long bit-fields are not 
necessarily promoted to long, so g++ happily generates operations on a 
51-bit integer type... (clang does promote IIRC)

> I see no nice solution to the C++ rule.  I suppose that if we decide to
> go with bit fields here, we will simply not support problematic C++
> compilers.  Or we arm autoconf to probe for this too, and stay away from
> stdint.h.

-- 
Marc Glisse