Bitfield subtlety

Richard Biener rguenther at
Wed Mar 28 07:58:04 UTC 2018

On Wed, 28 Mar 2018, Niels Möller wrote:

> tg at (Torbjörn Granlund) writes:
> > 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.
> Ouch, it's pretty subtle (and unfriendly) if "long" and "signed long"
> don't quite mean the same thing. And remedying by writing something like
> "signed int64_t" isn't valid either?
> > 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.
> Or stick to a single uint64_t and shift and mask operations to access
> the fields.

I would also suggest that.  Simply hide it behind some nice macros
(ugh..).  Note I'd use two uint32_t fields because otherwise you
may end up breaking the ABI via increased alignment requirement
of uint64_t for the struct.


> Regards,
> /Niels

Richard Biener <rguenther at>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)

More information about the gmp-devel mailing list