My question is pretty simple: as std::intmax_t
is defined as the maximum width integer type
according to cppreference, why it does not correspond to __int128_t
in GCC?
相关问题
- Sorting 3 numbers without branching [closed]
- Multiple sockets for clients to connect to
- How to compile C++ code in GDB?
- Do the Java Integer and Double objects have unnece
- Why does const allow implicit conversion of refere
Changing
intmax_t
requires not only changes to a compiler but also to numerous standard library functions that need to acceptintmax_t
arguments (and platform ABIs may defineintmax_t
as well). A compiler can unilaterally provide__int128_t
as an extension, but it cannot unilaterally change the typeintmax_t
. That requires support from all of the standard library implementations that the compiler targets.I believe this is a violation of the C and C++ standards -- either that, or gcc doesn't consider
__int128_t
to be an integer type.The C standard (both the 1999 and 2011 editions) doesn't require
intmax_t
to be one of the standard types; it's required to be "a signed integer type capable of representing any value of any signed integer type". In particular, it can be an extended integer type -- and if there is a 128-bit extended integer type, thenintmax_t
must be at least 128 bits wide.The C standard even suggests using implementation-defined keywords that "have the form of an identifier reserved for any use" as the names of extended integer types -- such as
__int128_t
.The 2011 C++ standard adopts C99's extended integer types feature, and defers to the 1999 C standard for the definition of
intmax_t
and<stdint.h>
.So if
__int128_t
is an integer type within the meaning defined by the standard (which it certainly can be), and is, as the name implies, 128 bits wide, thenintmax_t
must be at least 128 bits wide.As Stephen Canon's answer, changing
intmax_t
does require some work. The C and C++ standards do not recognize that as a justification for definingintmax_t
incorrectly.Of course all of this applies equally to
uintmax_t
.On my system (Linux x86_64, gcc 4.7.2), the above program prints:
If gcc conforms to the standard, then that should be possible only if
__int128_t
is not an integer type -- but quoting the gcc 4.8.2 manual (emphasis added):I suppose one could argue that the "as an extension" phrase lets gcc off the hook here, justifying the existence of
__int128_t
under section 4 paragraph 6 of the standard:rather than under section 6.2.6 paragraph 4:
(I personally think that making
intmax_t
at least as wide as__int128_t
, if it exists, would be more in keeping with the intent of the standard, even if it's (barely) possible to argue that it doesn't violate the letter of the standard.)__int128 is not sufficiently functional to be used as an intmax_t
The stdint.h header must include a define INTMAX_C(9999999999999999999999) This define lets you enter a constant into the C source for any value up to the maximum size of the type.
The GCC documentation says "There is no support in GCC for expressing an integer constant of type __int128 for targets with long long integer less than 128 bits wide."
Therefore, it cannot be used for intmax_t.