Clearly some of us do more awful things with the preprocessor than others... ;-)
-
-
Replying to @RichFelker @cr88192 and
I inserted the "almost" just for you.
2 replies 0 retweets 3 likes -
Replying to @stephentyrone @cr88192 and
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.
1 reply 0 retweets 2 likes -
Replying to @RichFelker @stephentyrone and
I should probably replace with
#if '\xff' > 0, no? EXAMPLE 2 under 6.4.4.4 explicitly blesses this usage, I think.1 reply 0 retweets 0 likes -
Replying to @RichFelker @stephentyrone and
Wait, so the reason we don't have uint128_t/int128_t is because uintmax_t/intmax_t??
2 replies 0 retweets 1 like -
Replying to @stevecheckoway @stephentyrone and
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.
2 replies 0 retweets 0 likes -
Replying to @RichFelker @stevecheckoway and
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.
1 reply 0 retweets 1 like -
Replying to @RichFelker @stephentyrone and
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.
1 reply 0 retweets 1 like -
Replying to @stevecheckoway @stephentyrone and
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 replies 0 retweets 3 likes -
Replying to @RichFelker @stevecheckoway and
File this one away for adversarial C implementations.
1 reply 0 retweets 6 likes
Something like this would actually not be so unreasonable when coding for halfass support of legacy C89-ish compilers:
#if !defined(INT32_MIN) && INT_MIN==-1-2147483647
typedef int int32_t;
#define INT32_MIN INT_MIN
#define INT32_MAX INT_MAX
#endif
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.