Rejecting is a problem because aarch64 went and made it part of the ABI for their ucontext structure and maybe other things...
-
-
I inserted the "almost" just for you.
-
See http://git.musl-libc.org/cgit/musl/tree/include/limits.h?id=v1.1.19#n10 …, which depends on I-think-likely-wrong behavior by gcc and other compilers of treating char constants as uintmax_t rather than intmax_t if char is unsigned.
-
I should probably replace with
#if '\xff' > 0, no? EXAMPLE 2 under 6.4.4.4 explicitly blesses this usage, I think. -
Wait, so the reason we don't have uint128_t/int128_t is because uintmax_t/intmax_t??
-
Yes, exactly. __int128 has to be treated as an implementation-defined type with implementation-defined semantics, not as an extended integer type in the framework C set forth, because the latter would require redefining intmax_t.
-
Specifically, if int128_t (and INT128_MAX, which would be testable at preprocessor level rather than just "configure level") were defined, INTMAX_MAX>=INT128_MAX would be mandatory and intmax_t would have to have rank >= rank of int128_t.
-
What about allowing integers larger than intmax_t by not defining a corresponding INT_<size>_MAX and keeping the limit of the preprocessor to intmax_t? INT_MAX is useful because the size of an int isn't fixed. But you know the max of a uint128_t.
-
Arguably, since the standard requires INTnnn_MAX to be defined if intnnn_t is, I think it's valid for the application to use the identifier intnnn_t if INTnnn_MAX is not defined... ;-)
- 2 more replies
New conversation -
-
-
preprocessor: the poor mans TMP ;)
-
TMP: the poor man’s ruby script which generates boat loads of C++.
-
but with fine-grained control and no build dependencies on ruby ;)
-
I for one am glad the STL does not build on top of ruby
-
OTOH if they said Perl ...
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.