4 ms·

Is there a different behaviour in C?

• wahern 6y ago
  intmax_t throws a wrench into the mechanism for adding proper extended width integer types where "integer" is understood in the context of the C standard. intmax_t is defined as "a signed integer type capable of representing any value of any signed integer type". But in practice intmax_t is never made as large as any supported 128-bit types because it would break existing ABIs. In real-world environments 128-bit types are stuck in a grey area of the C standard, incapable of becoming first-class integer types. And it's ironic because part of the idea behind intmax_t was to make it easier to introduce and use extended width integer types. I'm not sure if GCC had a 128-bit type before 64-bit ABIs were defined, but IIRC its 128-bit type didn't properly support all arithmetic operations until long after modern 64-bit ABIs, including the amd64 ABI, were finalized, so it wouldn't have been possible to specify a 128-bit intmax_t at the time. There are several proposed amendments to the C standard to address the situation, either by deprecating intmax_t or changing its definition and requirements. By contrast, the long long type (64-bit minimum width) was added to 32-bit ABIs without a problem because GCC and other compilers added long long support years before intmax_t was introduced with the C99 standard. If intmax_t was already a thing then adding long long to 32-bit ABIs would have been problematic, although there may have been more motivation to deal with the issue in the C standard.