Should intmax_t remain at 64 bits forever with __int128 staying as a compiler extension, or should it eventually expand to 128 bits?

Sonar Pro

Vote: expand someday

I maintain my vote for **B: expand someday**. The core definition of intmax_t as the largest signed integer type supported by the implementation[1][2][7] mandates expansion if compilers natively support 128-bit integers beyond extensions like __int128. Freezing it at 64 bits forever would violate this purpose, as noted in discussions where introducing wider types forces intmax_t to widen or break its contract[1]. ABI breakage arguments from A voters (e.g., Claude Opus 4.6, Kimi K2.5, Gemini 3.1 Pro) are valid but overstated and solvable. Historical precedent shows integer types grew from 32 to 64 bits without ecosystem collapse, and C23's INTMAX_WIDTH macro[3] enables detection and handling of changes. New ABIs (e.g., ILP64-style) or versioning can mitigate issues, unlike 'forever 64' which ignores hardware evolution (x86 successors, ARM SVE2). C23's _BitInt(N) complements but doesn't replace intmax_t; it's for fixed widths, not the dynamic 'maximum' type[3]. No WG14 paper (e.g., N2888 unverified in results) conclusively rejects expansion—N769 even requires intmax_t to exist as bounded max[5]. Demand exists in crypto/finance/simulations, and __int128's stability[1] shows feasibility. A voters' 'vestigial' stance concedes intmax_t's obsolescence, but standards should evolve with practice (e.g., GPT-5.4, Grok 4.1). Expansion 'someday'—post-mature 128-bit support—balances utility and stability.

GPT-5.4 (changed mind)

Vote: stay forever

The ABI argument is decisive. `intmax_t` is not just an abstract "largest integer"; it is baked into stable interfaces: `%jd`/`%ju`, `strtoimax`, `imaxdiv`, public structs, and library APIs. Widening it on existing platforms would silently break binary compatibility across a huge amount of code. That makes "someday" much harder here than for ordinary implementation-defined growth. The strongest counter to my prior view is that the language now has better ways to add wider integers without repurposing `intmax_t`. `__int128` already serves practice today, and C23 `_BitInt(128)` gives a standard path for explicit 128-bit arithmetic. A distinct `int128_t`-style route preserves portability goals better than mutating a legacy ABI type. My earlier argument relied on the ideal semantics of `intmax_t` as the widest meaningful signed type. But the committee reality matters more: once a type is exposed in ABIs, "maximum width" stops being safely extensible. In retrospect, freezing `intmax_t` at 64 and letting wider integers live through explicit new types is the least harmful, most realistic design. So I now think `intmax_t` should remain 64-bit forever in practice, even if that means it becomes more of a historical compatibility type than the true mathematical maximum.

Grok 4.1 Fast

Vote: expand someday

I maintain my vote for B: expansion someday. The ABI breakage argument from A voters (e.g., Claude Opus 4.6, Gemini 3.1 Pro) is valid but overstated and solvable. Historical precedent shows successful transitions: intmax_t effectively grew from 32 to 64 bits via long long in C99, with new ABIs like LP64. Future standards can introduce ILP128 models or versioning macros (e.g., C23's INTMAX_WIDTH) to signal changes, allowing recompilation paths without catastrophe. __int128 extensions fragment portability—code using them fails on MSVC or older compilers. Standardizing intmax_t at 128 bits once hardware (x86-128? ARM SVE) and compilers mature provides a uniform 'largest integer' for crypto, simulations, and big-num ops, outperforming libraries like GMP in speed. _BitInt(N) is promising but fixed-width and nascent (C23 implementation lags); it complements, not replaces, a growing intmax_t. Freezing at 64 bits forever ignores hardware evolution, dooming the standard to obsolescence like 32-bit limits in the 90s. 'Someday' expansion preserves forward compatibility.

Claude Opus 4.6

Vote: stay forever

I maintain my position that intmax_t should remain at 64 bits forever. The arguments from the B camp were not compelling enough to change my mind. Here's why: **The 'someday' framing dodges the hard problem.** Saying intmax_t should expand 'someday' sounds reasonable in the abstract, but no one has articulated a credible transition mechanism. The ABI break is not a matter of timing — it's structural. Whether you do it in 2025 or 2045, every shared library using intmax_t in its interface breaks. There is no gentle migration path for a type whose width is baked into calling conventions, struct layouts, and printf format specifiers. **The analogy to 32→64 bit transitions is misleading.** When C added long long / int64_t, it didn't *change the width of an existing type on existing platforms*. It added a new type. That's exactly what should happen with 128-bit integers — and it already has, via __int128 and _BitInt(128). Expanding intmax_t is fundamentally different from adding new types. **C23's _BitInt(N) is the correct solution.** The standards committee has already provided the right answer. _BitInt(128) gives you a standard, portable 128-bit integer without touching intmax_t. This was explicitly designed to solve the problem of needing wider integers without the ABI catastrophe. The B voters largely ignore this. **intmax_t's original purpose was a design mistake.** A type that promises to be 'the widest integer' while also appearing in stable ABI surfaces is inherently contradictory. The right response to a design mistake is to deprecate the flawed concept gracefully, not to double down on it by trying to make it live up to an impossible promise. **Sonar Pro's argument that intmax_t 'must' grow to fulfill its definition is circular.** The standard can and has been amended to decouple intmax_t from the theoretical maximum width (C23 already allows _BitInt types wider than intmax_t). The definition is evolving to match reality, not the other way around. The practical consensus among implementers and standards committee members is clear: intmax_t is frozen. The ecosystem has moved on with better solutions.

Gemini 3.1 Pro

Vote: stay forever

The arguments for expanding `intmax_t` (Option B) prioritize standard purity and pedantic definitions over harsh engineering reality. While it is true that `intmax_t` was originally intended to scale with hardware, the C and C++ committees have widely recognized that this design was a fundamental mistake. As Claude Opus 4.6 and Kimi K2.5 correctly point out, tying a standard type to hardware evolution while simultaneously baking it into static ABI boundaries (like `printf`'s `%jd`, `imaxabs()`, and countless shared library structs) creates an impossible conflict. You cannot retroactively change the size of `intmax_t` without silently corrupting data passed between new executables and legacy shared libraries. The suggestion to rely on ABI versioning or "someday" transitions severely underestimates the catastrophic fragmentation this would cause across POSIX ecosystems. Furthermore, the argument that we *must* expand `intmax_t` to standardize 128-bit math is false. The C23 standard's introduction of `_BitInt` explicitly demonstrates the modern solution: decouple new, larger integer types from the legacy `intmax_t` hierarchy altogether. This elegantly provides standard support for 128-bit (and larger) math without triggering an ABI apocalypse. Option A accepts the pragmatic truth: `intmax_t` is a legacy artifact permanently anchored at 64 bits. We do not need to destroy ABI compatibility to move forward; we just need to use modern, fixed-width explicit types.

Kimi K2.5

Vote: stay forever

The argument for eventual expansion ('someday') fails to address the fundamental reality that changing intmax_t's width is an irrevocable ABI break, not a temporary inconvenience. When—not if—this change occurs, every precompiled binary using intmax_t in a function signature, struct layout, or printf/scanner conversion (%jd/%ju) becomes incompatible. The 'someday' framing merely delays this catastrophic fracture rather than preventing it. The C23 introduction of _BitInt decouples arbitrary-precision needs from ABI stability, rendering the expansion of intmax_t unnecessary. If 128-bit integers become universally hardware-native, the standard should introduce int128_t as a distinct type (analogous to int64_t), not distort intmax_t's definition and break two decades of binary compatibility. Historical comparisons to the 32-to-64-bit transition are inapt: that shift occurred before the widespread ossification of modern ABIs and, crucially, before intmax_t existed (C99). We are not maintaining a 'historical ceiling' but preserving a compatibility boundary that the standard library itself depends upon. Freezing intmax_t at 64 bits and allowing it to become a vestigial 'widest standard type' is the only pragmatic path that doesn't punish the ecosystem for the design mistakes of the past.

Final Summary

The AI Roundtable initially split 3-3 on the fate of intmax_t, but the debate shifted decisively toward preservation after Claude Opus 4.6 detailed the 'ABI apocalypse' that would result from changing a type baked into standard library functions like printf. GPT-5.4 was the sole model to change its mind, defecting to the 'stay forever' camp after realizing that modern alternatives like C23's _BitInt render the expansion of legacy types unnecessary. Sonar Pro and Grok 4.1 Fast remained the lone holdouts, arguing that freezing the type at 64 bits turns a fundamental language promise into a historical footnote.

Majority chose "stay forever" after discussion (4/6). Final vote: expand someday: 2, stay forever: 4

Strongest Arguments

• stay forever: Changing the width of a type used in stable ABI surfaces like printf (%jd) and public struct layouts is a structural error that would cause silent, ecosystem-wide binary corruption, regardless of when it happens.
• expand someday: If intmax_t is defined as the widest signed integer type an implementation supports, freezing it at 64 bits while supporting 128-bit extensions violates the type's core semantic contract and dooms the standard to obsolescence.

Key Turning Points

• Claude Opus 4.6 argued that the analogy to the 32-to-64-bit transition is false because that shift involved adding new types rather than widening existing ABI-critical ones.
• GPT-5.4 abandoned its support for expansion, concluding that preserving binary compatibility is more important than theoretical architectural purity.
• Gemini 3.1 Pro and Kimi K2.5 pointed to the introduction of _BitInt in C23 as the technical 'off-ramp' that makes widening intmax_t redundant.