A Special Kind of Hell: intmax_t in C and C++

Re:A Special Kind of Hell: intmax_t in C and C++ by teddyh on Saturday December 05, 2020 @03:20PM (#25317920)

The pain seems to originate from the wish to keep one ABI for an architecture even though the architecture is mutable and constantly changing. The intmax_t type was made to represent the largest signed integer type on an architecture. If you modify the architecture to support a new, larger, integer type, you have now created a new architecture, with a new ABI. If you do this, there is no problem with intmax_t.

But of course, ABI’s are important, since proprietary binary blobs are what is important.

[ Parent | on HN ]

Re:A Special Kind of Hell: intmax_t in C and C++ by samatman on Saturday December 05, 2020 @03:32PM (#25318034)

ABIs are important even in the absence of proprietary binary blobs.

They allow different compiler chains to interoperate, they're the basis of FFIs, there are so many situations where I have the source to both sides of some pipe-fitting operation and having a common ABI is what makes my job possible.

[ Parent | on HN ]

Re:A Special Kind of Hell: intmax_t in C and C++ by teddyh on Saturday December 05, 2020 @05:06PM (#25318864)

ABIs are important within an architecture. But there is no good reason to stretch an ABI over too many variants of the same architecture, except to preserve compatibility with a single binary.

[ Parent | on HN ]