Lacking a good suffix for __int128, in my C compiler (mostly used for targeting my own experimental ISA designs) I just went with LLX / ULLX.
-
-
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... ;-)
-
File this one away for adversarial C implementations.
-
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.