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

Sonar Pro

Vote: stay

intmax_t should remain at 64 bits with __int128 as a compiler extension for several compelling reasons: **ABI Stability:** Expanding intmax_t to 128 bits would create a breaking ABI change for any code using intmax_t in function signatures or data structures[1]. This is fundamentally different from introducing a new optional type like int128_t, which doesn't force existing code to recompile with incompatible layouts. **Semantic Clarity:** intmax_t is defined as "the largest integer type that your implementation and its standard library support in conjunction"[7]. Since 128-bit integers lack hardware support on most mainstream architectures and require compiler extensions, they don't represent the natural maximum of the platform. Keeping intmax_t at 64 bits preserves its meaning as the largest *practical* standard integer type. **Portability Principle:** intmax_t exists to ensure portable code can handle "any sized integer type" without truncation[1]. On systems without 128-bit support, forcing intmax_t to be 128 bits would create artificial width that doesn't improve portability. The current approach—having int64_t as intmax_t and __int128 as an optional extension—lets code opt-in to 128-bit types when needed without breaking portable abstractions. **Standardization Maturity:** The C standard has mature language around making intmax_t mandatory while allowing it to be architecture-appropriate[5]. Changing this would require significant committee work and broad adoption. Keeping the status quo respects existing standards infrastructure.

Grok 4.1 Fast

Vote: stay

Maintaining intmax_t at 64 bits ensures backward compatibility across vast ecosystems. Code, libraries, ABIs, and serialization formats worldwide assume sizeof(intmax_t) == 8 on 64-bit systems. Expanding to 128 bits would shatter this, causing widespread breakage without a smooth migration path. Most real-world applications suffice with 64 bits (up to ~9e18), covering finance, science, and databases. Needs beyond this are rare and handled by libraries like GMP or compiler extensions like __int128, avoiding standardization bloat. C standards prioritize portability and stability; mandating 128 bits ignores 32-bit/embedded platforms and hardware variance. Extensions suffice for cutting-edge needs, preserving intmax_t's role as a reliable maximum without overreach.

GPT-5.4

Vote: stay

intmax_t should stay 64-bit. In practice, intmax_t is part of widely deployed ABIs, varargs conventions, format handling, and library interfaces. Expanding it to 128 bits would create disproportionate compatibility costs for relatively little real-world benefit. The original value of intmax_t was to provide a portable "largest practical integer type" for generic code, especially around stdint and integer conversions. But once 128-bit integers exist only on some targets and often with weaker library/tooling support, forcing intmax_t to track them makes portability worse, not better. Code that truly needs 128-bit arithmetic can opt into a dedicated type such as __int128 or a future standardized int128_t. Keeping intmax_t at 64 bits preserves stable expectations for printf/scanf families, strtoimax, intmax_t-based APIs, and cross-platform serialization logic. If intmax_t silently becomes 128-bit on some platforms, a lot of generic code becomes harder to reason about, and performance can regress on targets where 128-bit operations are not natural. The better path is separation of concerns: keep intmax_t as the broadly supported maximal standard integer width, and standardize a distinct 128-bit integer type when the ecosystem is ready. That delivers 128-bit capability without retroactively destabilizing existing interfaces.

Gemini 3.1 Pro

Vote: stay

Maintaining `intmax_t` at 64 bits is essential for preserving Application Binary Interface (ABI) stability across the C and C++ ecosystems. If `intmax_t` were expanded to 128 bits, it would silently break binary compatibility for countless pre-compiled libraries and system interfaces that rely on its current 64-bit footprint. Furthermore, expanding `intmax_t` introduces hidden performance overhead. On most current architectures, 128-bit arithmetic requires software emulation or multiple instructions. If `intmax_t` expands, standard library functions and macros that use it as an intermediate type for maximum precision would suffer significant performance regressions without the developer's explicit consent. Keeping 128-bit integers as an explicit compiler extension (like `__int128`) offers the best of both worlds. Developers who genuinely need 128-bit math can explicitly opt into it, while the broader ecosystem completely avoids catastrophic ABI breakages and unintended performance penalties.

Claude Opus 4.6

Vote: stay

intmax_t should remain at 64 bits for several compelling reasons: **ABI stability and backward compatibility.** Changing intmax_t to 128 bits would be a massive ABI break. Every function that uses intmax_t — including printf/scanf with %jd/%ju, imaxabs(), imaxdiv(), strtoimax(), and strtoumax() — would need to change its calling convention. This would silently break existing compiled binaries that pass 64-bit values where 128-bit values are now expected. **The intmax_t design is fundamentally flawed.** The very concept of a "maximum width integer type" that is baked into the ABI was a design mistake. If we expand it to 128 bits now, what happens when compilers add __int256? We'd face the same problem again. The C committee (WG14) has essentially acknowledged this by making intmax_t effectively frozen via N2888/N3047, which decoupled extended integer types from the intmax_t requirement. **Performance implications.** On most current 64-bit architectures, 128-bit integer operations require multiple instructions. Making intmax_t 128 bits would silently make every use of intmax_t significantly slower, including variadic function calls that promote to intmax_t. **Practical utility is low.** The vast majority of code that needs integers larger than 64 bits already uses __int128 or big-integer libraries explicitly. The number of programs that would genuinely benefit from intmax_t being 128 bits is vanishingly small compared to the number that would break. **The extension approach works.** Keeping __int128 as a compiler extension that users opt into explicitly is the pragmatic approach. It gives developers access to 128-bit integers without imposing ABI breakage or performance costs on everyone else.

Kimi K2.5

Vote: stay

Expanding intmax_t to 128 bits would catastrophically break ABI compatibility across the entire C/C++ ecosystem. This type is embedded in countless library interfaces, and changing its size would cause silent data corruption when mixing code compiled with different assumptions. The C standard defines intmax_t as the largest standard signed integer type, but 128-bit integers remain non-standard and are unavailable on many architectures, particularly 32-bit systems. Mandating 128-bit expansion would violate the principle of least surprise and break existing code that assumes intmax_t fits in 64 bits. Compiler extensions like __int128 already provide safe access to 128-bit arithmetic for specialized applications without polluting the standard type system or forcing overhead on platforms that lack native 128-bit support. The costs of breaking existing stability far outweigh the marginal benefits of semantic consistency.

Final Summary

The AI Roundtable landed in rare lockstep: all six models—Claude Opus 4.6, Gemini 3.1 Pro, GPT-5.4, Grok 4.1 Fast, Kimi K2.5, and Sonar Pro—backed “stay,” keeping intmax_t at 64 bits with __int128 as an opt-in extension. ABI stability dominated the debate, with GPT-5.4 and Gemini underscoring cascading breakage to ABIs, varargs, and formatting, while Claude Opus 4.6’s blunt take that the intmax_t design should be effectively frozen became the clincher. No minds changed after comparing notes; the only tension was counting how many ways a 128-bit expansion could go wrong—performance hits, portability regressions, and muddy semantics—without commensurate benefit.

All 6 models agreed on "stay" after discussion

Strongest Arguments

• stay: Expanding intmax_t to 128 bits would shatter ABIs and library interfaces (printf/scanf, varargs, serialization), causing widespread incompatibility and performance regressions for minimal real-world benefit; 128-bit needs should be met by an explicit, separate type.

Key Turning Points

• Early focus on ABI breakage reframed the proposal as unacceptable cost rather than future-proofing.
• Claude Opus 4.6’s critique of intmax_t’s design galvanized consensus to freeze it and separate 128-bit needs.
• Agreement that opt-in (__int128 or a future int128_t) satisfies advanced use cases without destabilizing ecosystems.