Hi Paul, On 2020-10-02 22:19, Paul Eggert wrote: > On 10/2/20 1:03 PM, Alejandro Colomar wrote: >> I know it's not in stdint, >> but I mean that it behaves as any other stdint type.
With caveats, of course. > > It doesn't. There's no portable way to use scanf and printf on it. I didn't need to. Yes that's a problem. It may be possible to write a custom specifier for printf, but I didn't try. I wrote one for printing binary, and it's not that difficult. If you really need it, this might help: https://github.com/alejandro-colomar/libalx/blob/d193b5648834c135824a5ba68d0ffcd2d38155a8/src/base/stdio/printf/b.c > You can't reliably convert it to intmax_t. Well, intmax_t isn't really that useful. I see it more like a generic type, than an actual type. I guess you could have typedef __int128 intwidest_t; if you find it's useful to you. > It doesn't have the associated _MIN and _MAX macros > that the stdint types do. It's a completely different animal. Those are really easy to write. For my use cases, they have been enough. These might be useful to you: #define UINT128_C(c) ((uint128_t)c) #define INT128_C(c) (( int128_t)c) #define UINT128_MAX ((uint128_t)~UINT128_C(0)) #define INT128_MAX (( int128_t)(UINT128_MAX >> 1)) #define INT128_MIN (( int128_t)(-INT128_MAX - 1)) > > If all you need are a few bit-twiddling tricks on x86-64, it should > work. But watch out if you try to do something fancy, like multiply or > divide or read or print or atomics. There's a good reason it's excluded > from intmax_t. I know, they aren't perfect. But they are still very useful, and don't see a good reason to not document them. Cheers, Alex
