marc.glisse at inria.fr
Tue Mar 27 22:31:15 UTC 2018
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
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
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
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
More information about the gmp-devel