C's Flexible Integer Sizes Were Not a Design Mistake
pikuma.com
pikuma.com
Nonetheless, I started to use C for programming only in 1990, when I got access to the Microsoft C and Borland Turbo C compilers.
At that time, 36 years ago, the C flexible integer sizes were already obsolete.
Since that time until now, while using C on a great variety of computers, from servers and workstations to the smallest microcontrollers, I have seen plenty of portability problems created by the existence of the flexible integer sizes.
The only programs that had no portability problems were those that never used the flexible integer sizes, but only integers with a definite size, e.g. 8-bit, 16-bit, 32-bit or 64-bit.
While sizeof solves the problems of memory allocation or copying, it does not help in preventing unexpected integer overflows, because even the size of "char" may be unknown, and even if the size of "char" is known, writing code with multiple paths that would check or prevent overflow for different integer sizes is very cumbersome.
Flexible integer sizes would work well only on the old computers, where integer overflow generated a hardware exception, so installing an overflow handler would have been sufficient to make the C code work correctly regardless of the size of the native integers.
This is a highly ignorant comment. You're confusing the fact that you only had to work with a single target architecture with the whole concept of multiple processor architectures being somehow obsolete, as if there was a sudden law of nature that forced every single computer, being full blown HPC stuff or small microcontrollers used in embedded applications.
Take a look at arduino. They still have 16-bit models out there. Also noteworthy, it seems some DSPs also have ints larger than 32 bits.
For instance if your integer arithmetic needs to happen with 32 bit precision (no matter if the code runs on a 16- or 32-bit CPU), there is no scenario where using 'int' makes sense. Instead you'd use a fixed-width 32-bit integer type and accept that math operations are compiled into two instructions on a 16-bit CPU.
And OTH if you only require 16 bits integer width, there's not much point in picking a 32 bit integer type. Since two's-complement integer encoding has been standard since at least the 70s, the CPU can do narrow operations in the native register width. Any overflow/wraparound is still correct when only looking at the lowest 16-bits of the result.
You're confusing things. It's one thing to claim that either they never used a feature or they even have a personal preference to do things one way or another.
Another entirely different thing is to proclaim a programming language designed to target any conceivable CPU architecture somehow no longer needs to support basic cpu arch traits such as word size.
As I pointed out,there are still processors being sold today that do not support 32-bit ints. If you expect C to be able to target these architectures, obviously this feature is still a critical feature.
Also, people who maintain yesterday's systems that require non-32bit ints still need to work on them.
Chesterton's fence is still relevant. Why are we pretending that it's ok to mindlessly proclaim a feature is not requires because we don't understand why it was necessary to begin with?
word sized variable is relevant for performance, it is processed in exactly one cycle (I strongly suspect there is an asterix somewhere).
Most notable uses, where int makes sense over int32_t: array indexes, for-loop variables, enum, flags.
Some common architectures like x86 can suffer from an issue called partial register stalls. So from a performance perspective choosing a 32 bit integer can be better.
AFAIK, this was only an issue in some older CPUs and isn't a problem today.
32-bit `int` is still cheaper than 16-bits though, because 16-bit instructions require an operand size override prefix (0x66), or address size override prefix (0x67), or both. Technically, these aren't "16 bit prefixes" - if the machine was running in 16-bit protected mode, then you would need those prefixes to use 32-bit instructions and the non-prefixed ones would be 16-bit and thus cheaper, so `int` would be better as 16-bits in 16-bit protected mode - though this mode is essentially unused today, so for all intents and purposes the prefixes are used to issue 16-bit instructions and 16-bits is more expensive (in code size, i-cache usage, which may impact performance).
I don't see the problem if you end up with a type that is larger than what you asked for, because (assuming signed arithmetic) it was undefined to overflow anyway.
A C hacker (author of lighttpd) taught me ~20 years ago that you'd always choose the native register size for database indices that would be involved in JOINs even when you'd never expect to have so many records, because that's what the machine performs best on.
Before 1990, I had worked with a variety of ISAs, from IBM mainframes and DEC minicomputers to many kinds of microprocessors.
After 1990, I have used C on a great variety of x86, Motorola 68xxx, IBM/Motorola PowerPC and many generations of ARM ISAs.
Even if you use explicit 32-bit integers in a program, that will not create any correctness problem when the program is run on 16-bit microcontroller. At most such a program may have a suboptimal performance. Performance problems are much easier solved during porting than obscure bugs.
There have been some popular DSPs with 24-bit integers, e.g. Motorola 56xxx. Nonetheless, nobody would want to run on such a DSP a program that was written for another kind of CPU, even for another kind of DSP, because the performance would be pathetic. Any program for such a fixed-point DSP, even when derived from an existing program, would need to be rewritten while using at every point in the program the knowledge that the size of "int" is 24 bits (because the programs for fixed-point DSPs need copious amounts of scaling operations, to avoid overflows and underflows), so such a program should not actually use "int", but it should typedef an "int24_t", to make this assumption explicit.
So there has been a really long time in C's evolution where we haven't had fixed size types which has been a super annoying mess of #ifdefs in portable code.
The variable size ints have allowed some super weird architectures though. I remember looking at the datasheet for the Motorola 56000 DSP and noting that the C compiler set char = short = int = 24 bits! That was because the hardware could not address anything smaller than 24 bits. I think long could be 48 bits.
Give me `int*` vs `PINT`. Microsoft really likes to over engineer causing you have to pointlessly remember more.
The worst is when they redefine the same structure or union under a different name. Example: `IP_ADAPTER_ANYCAST_ADDRESS_XP` is the exact same as `IP_ADAPTER_MULTICAST_ADDRESS_XP`.
https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...
There was a change of heart a few years later, but the wind seems to have stopped after all the security discussions,
https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-...
https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...
A few years later they backtracked on it,
https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-...
Until the SFI came into play,
https://www.microsoft.com/en-us/trust-center/security/secure...
Char is actually guaranteed by C to occupy exactly 1 byte in memory. It’s just that a byte can have more than eight bits in C. “Byte” is simply the smallest unit of memory addressable by a pointer.
Further down the article acknowledges that “C requires char to have at least 8 bits (CHAR_BIT >= 8), not exactly 8” and mentions the Honeywell 6000 as an example of a C implementation with 9 bits (and 36-bit ints).
Historically in computing, the size of a byte was hardware-dependent and not standardized. The Wikipedia article on “byte” cites Knuth’s 1968 TAOCP where byte denotes a unit which “contains an unspecified amount of information […] capable of holding at least 64 distinct values […] at most 100 distinct values. On a binary computer a byte must therefore be composed of six bits”.
The famous TI C55x DSP with 16 bits byte for example: https://news.ycombinator.com/item?id=3112704.
And they are still available new for purchase.
In hindsight though, it was a mistake.
Evidence: when the world moved to 64 bit, we didnt just let int mean 8 bytes on amd64. That's a clear acknowledgement that the design was not correct once we understood things better.
When amd64 was released, x86 was almost ubiquitous on desktops and ran the majority of servers - most of the software used by the world could continue being used. If AMD had not gone through this effort to make it backward compatible, it's likely IA64 would've won and we wouldn't have this debate. Hard to understate the importance of not breaking things.
If you were designing a greenfield 64-bit ISA, then yes, it might make sense to have `int` be 64-bits, but it was definitely not, and still is not a mistake that it's 32-bits on amd64.
On RISC-V for example, it's questionable. The RV32 ecosystem is tiny and almost irrelevant - if they decided to break things for RV64 it wouldn't be a big problem - probably better to fix any problems early rather than hold baggage to run software that never existed - though it's much easier to port software to RV64 if `int` is still 32-bits.
They called it 'int' instead of 'int32_t' because it was meant to be the natural word size. It was supposed to float as the natural word size increased and allow code that worked on one word size to transparently work on the new word size.
Not floating to 64-bits on amd64 means their rationale for not giving it a fixed size was wrong. That is a simple width-doubling to another power of 2, the easiest possible case to expect to work transparently, on a compatible instruction set and they still chose to not float the size.
You can not just transparently change the word size and expect it to work, so you should just fix the size or use a fixed size. The notion of only having floating sizes as primitives was a mistake.
Probably someone noticed that it is inconvenient, and on 64-bit machine ints are still 32-bit and not 64.
The computers with 16-bit ints or 9-bit bytes are long gone, but the language still has to carry that legacy.
C would probably not have survived unless it had this flexibility.
But its not justa historical thing. Today there are modern platforms like DSPs that have 32bit sized char, because that is the smallest addressable type. These platforms depend on C for tool chains, even if most "portable" C wont run correctly on them. The fact that you can build hardware like that, and not have to invent a new language / dialect to program them is a huge win for the world.
<edit> I didnt see the footnote about DSPs at first read </edit>
DEC's VAX/VMS became Open VMS when UNIX/POSIX support was added in the early 1990's as well.
Other mainframe systems added similar POSIX environments.
The way Windows NT OS linage works isn't something novel, it is how mainframes have introduced multiple OS personalities and virtualisation modes since the late 70's.
Traditionally this was a profitable niche, Microsoft would like to take a fat piece of that, and instead what happened is that Linux destroyed the profit margin. A million dollars overhead that would have kept a hungry UNIX® vendor alive on your project didn't turn into an extra million dollars on Microsoft's balance sheet, instead it evaporated because Linux is "free". And so then Microsoft lost interest.
WSL is Redmond going OK yeah, here you go, an actual Unix.
The point still stands, that POSIX checkbox was relevant enough for spending the money in engineers salary during Windows NT 3.51 development.
For those that don't read standards, POSIX certification requires the existence of a C compiler, the more recent one being C17 compliant.
https://pubs.opengroup.org/onlinepubs/9799919799/utilities/c...
C was pretty much ignored on 8 bit home computers, outside some toy compilers for CP/M.
In the 16 bit days, it was yet another language alongside BASIC compilers, Pascal, Modula-2, Assembly.
C is so tied to UNIX, that POSIX had to be created so that any non-UNIX operating system could provide a cozy home for their C compilers.
UNIX/POSIX is for all practical purposes the runtime most C applications rely on, there are naturally some exceptions like free-standing or Windows (which eventually gave up and add to start improving its support).
It is only due to historical accident that Microsoft gave up on Xenix, instead of replacing their MS-DOS efforts.
And many projects properly abstract their OS layer so they aren't tied to POSIX.
Maybe Unix is tied to C, but C isn't tied to Unix.
> UNIX/POSIX is for all practical purposes the runtime most C applications rely on, there are naturally some exceptions like free-standing or Windows (which eventually gave up and add to start improving its support).
C was invented to rewrite UNIX in a programming language that made it easy to port UNIX between machines.
So what you're saying is contradictory. You're saying the underlying motivation of C was wrong or unnecessary (porting UNIX to different hardware architectures) but C won because that underlying motivation (easy porting between hardware architectures) was partially right.
Your position is now that C didn't need UNIX as a stopgap, which is weird because your argument gains no weight (basically saying C's dominance is sheer coincidence) if it's true but if it's false you're just plain wrong.
On the consoles it took until PlayStation for C to take off among game devs.
Additionally many Amiga games used Blitz BASIC and AMOS.
Anyone involved in the Demoscene early days would be 100% Assembly as well.
On PC, it required until Watcom with its great MS-DOS extender for devs to finally move away from Assembly in mass.
I was there, Gandalf ;)
(and note how I specifically wrote "dominant high level language", not "dominant language", since assembly coding was indeed very relevant on those machines, for UI apps 100% assembly was quite rare though, and hybrid C/ASM seems to have been more common).
In my part of the Iberian Penisula it was Turbo Pascal on PC and AMOS/Blitz Basic on Amiga.
With lots of inline Assembly anyway.
It depends: for the classic 8 bit home computers, games were mostly written in assembly. Later DOS games were commonly either written in Pascal or C, but quite a bit off Assembler code was often used for the more performance-critical code sections.
I have seen code where folks used Pascal or C compilers as poor man's macro assemblers, the "quite a bit" was rather large.
Games that had quite a bit of code that profited from the higher-level abstractions that C/Pascal provided, such as
- resource management (including dynamic asset loading/unloading)
- enemy AI
- pathfinding
- ...
of course typically contained a lot more C/Pascal code than games that were more on the "multimedia demo" side with a simpler game logic.
UNIX was ubiquitous in the data center well before Linus even posted his first version of Linux on USENET.
Everything ran on SunOS, HP-UX, IRIX, AIX, etc.
?!? What a claim!
We don't make this mistake about JavaScript; nobody tries to argue that the confusing semantics of the "var" keyword or the "==" operator somehow were actually instrumental to its success. It's obvious that JavaScript won because it was what was on the web. Maybe C is not much different.
JavaScript and Web, UNIX and C, UNIX/Windows/Mac OS/OS/2 and C++, Ruby and Rails, Zope and Python, Tcl and AOLServer/Vignette, Windows and VB, 8 bit computer ROMs and BASIC, and so on.
On modern computers, it is impossible to write correct C programs that are agnostic about the true size in bits of the "flexible" types char, short, int, long and long long.
If your program must depend on assumptions about the size in bits of the integer types, those assumptions must be made explicit, by using types like int16_t, int32_t etc.
Writing correct programs that are agnostic about the integer sizes is possible only in programming languages that allow the programmer to install an integer overflow handler even if the CPU does not generate a hardware exception for that, in which case the compiler must insert appropriate overflow checking instructions that would invoke the installed handler when necessary.
This problem did not exist on old computers, where there were hardware exceptions for integer overflows, so even in C you could install a signal handler for SIGFPE, which would also be invoked by integer overflows.
I have never considered that this is an acceptable solution, which is why in decades of using C, during which I had many times to port programs or even entire real-time operating systems between different ISAs, I have never used those minimum sizes.
Instead of having those minimum sizes, which I consider useless, C should have had since the beginning, besides sizeof, which gives the size ratio between another type and char, another operator or macro to provide the size in bits of any integer type.
With that, it would have been possible to use types like short, int or long in a portable way.
Nowadays, there are _WIDTH, _MAX and _MIN constants for the integer types, but those have been added relatively late to the language, together with the integer types with specified width, for which those constants are superfluous.
#include <limits.h>
#if INT_MIN == 32767 && INT_MIN >= 2147483647L
# error too small
#else
# error just right
#endif
This is why I think so many C developers have no clue what they are doing. They just take whatever decision was made in C as gospel instead of thinking of everything being up for negotiation.
Shouldn't they be 64 bits on most modern systems then?
But porting 32-bit code to 64-bit was a big deal back then, and C99 with its new fixed-width integer types overlapped with the first AMD64 CPUs (and Microsoft's MSVC didn't start to support C99 until around 2015 anyway), I guess keeping int on 32-bits in the popular compilers was deemed 'safer' for porting existing code. I guess we can already be lucky that all the big compilers agreed on the same int width.
The amd64 design could run most 32-bit code with minimal changes. All the 32-bit instructions had the same encoding, besides push/pop which instead acted on 64-bits. The 64-bit instructions were basically opt-in, though a few opcodes (0x40..0x4F) had to be deprecated for the REX prefix.
This was the main reason that in stayed 32 bits. Not because larger footprint of structs would be catastrophic — it wouldn't: the 64-bit migration was motivated mainly by the fact that the 32-bit architectures couldn't easily address all that actually existing physical memory past 4 GiB (and virtual memory as well) — but because lots and I mean lots of on-disk data structures were defined in terms of char/short/int, people routinely dumped/gulped their data structures as-is, with no marshalling, so changing the size of int would break literally everything that worked with on-disk data, starting with the filesystem implementations themselves.
Arguably so, but then one would lose the ability to natively name 16-bit integer types because "short" would be 32 bits.
An earlier comment addresses x86-64. AArch64 (pedantically, the A64 instruction set used for AArch64's 64-bit execution mode) is similar, in that addresses are 64 bits wide but ALU instructions typically encode a width bit, called "sf", that selects either 32- or 64-bit data registers and arithmetic. See, for example, https://arm.jonpalmisc.com/latest_aarch64/add_addsub_ext .
Not sure how what you said makes sense.
Then again, we'd still have stdint around. And ultimately this doesn't matter because most code isn't portable anyway.
It would be odd for there to be a compiler intrinsic type to be unavailable until a header was included.
The compiler intrinsic type could be a mess like __int16_exactly_t but without it stdint.h would have some magic line which makes a compiler intrinsic available which wasn't before, or generates a new 16-bit type ex nihilo.
So you could have a "#pragma expose_extra_types" in stdint.h but that would not be the conventional approach.
I mostly wanted to make the point that a mere "at least 16 bits" type is not sufficient for some use cases, which is not in response to you but the comment you responded to.
typedef unsigned __attribute__((mode(HI))) uint16_t;
typedef signed __attribute__((mode(SI))) int32_t;
The added compatibility between 32 and 64 bit systems, is another reason. Also if you choose int to be 64 bits, what would you make short? 16 or 32 bits? It makes much more sense to keep int 32 bits, and reserve long / long long for 64 bits.
I agree with the article of course. I think most confusion comes not having learned about the purpose of having them be defined based on the architecture in the first place. It took me a long time before I stumbled upon how they really worked and why, because while I started it was either x86 or nothing. When x64 showed up, suddenly it became relevant and everybody started learning about C types more in depth as they ran into issues with sizeof.
Also, misuse in data protocols is where I think the bad reputation of the flexible type sizes came from. stdint was desperately needed for that reason and it came a bit late.
So the best solution for nowadays is to use just char, short, int and long long (and make strong assumptions that these are exactly 8, 16, 32 and 64 bits wide respectively), never use long or long double. Never use (u)intNN_t. Then you are good.
Those caveats of the past (but int might be 16 or 36 bits), are exactly that. An artifact of the past. A historical curiosity. Not relevant for today or the future. No, I don't believe for a second that any future platform will change their size.
Platforms also still disagree on the signedness of char, so when an 8 bit numeric type (as opposed to an ascii character type) is needed, one should always explicitly specify signed char or unsigned char, both of which are separate types from char.
Further things of note: platforms also have agreed on little endian (so called "network byte order" is dead and should never be used in new protocols, because it forces everyone to convert) and on IEEE memory representation of float and double. Contrary to popular belief the main floating point operations (+,-,*,/,==,<,>,<=,>=) are also precisely defined and always behave exactly the same (leaving out strange edge cases such as denormals). And yes, of course platforms have very long agreed on twos-complement for negative integers. This even made it into the standard at some point, I believe. Same happened with the memory layout of a vector<>, which in the past wasn't standardized, but because everyone of course did the obvious (and made it the same as a normal C array), it was added to the standard later.
What I am saying, what the C++ standard guarantees isn't everything. There are much more guarantees modern C++ code can (and should) rely on.
ILP64 (wherein int is 64 bits) exists. It's not very popular, but it exists; e.g. ICC supports it. So it happened in the past once already; it may again happen in the future. In any case, predicting the future is very hard, you really shouldn't be doing this.
> IEEE memory representation of float and double
Wait, what? I'm fairly certain that a) IEEE does not mandate the in-memory representation, and b) ARM actually uses big-endian byte order for floats/doubles when storing them in memory.
> always behave exactly the same (leaving out strange edge cases such as denormals)
So not always, but please pretend so? Yeah, no, thank you.
> platforms have very long agreed on twos-complement for negative integers. This even made it into the standard at some point, I believe.
Only in C23. It was explicitly rejected for C++ 23 (and C++ 26 too, I believe).
> but because everyone of course did the obvious
No, not everyone did the obvious. That's why it took so long to standardize because divergent implementations existed.
> There are much more guarantees modern C++ code can (and should) rely on.
As long as you only use only GCC (or Clang) exclusively, yes, you can. Otherwise, no, you can't and shan't.
That's not how I interpret section 3.2 in the standard[1]. Figure 1 seems quite explicit in how a single and a double should be encoded. The section on extended values specify they can be encoded in an implementation-depended manner, which makes the case stronger IMO.
edit: I note that in the 2008 revision[2], it's more explicitly mentioned that the specified encoding is a binary interchange format. So that's a lot more specific than the original.
And of course, if you accept the network byte order as the one intended for the interchange, then IEEE-754 mandates big-endian encoding.
ILP64 is problematic for existing code: there is lots of stuff like hashcode computations using uint32_t with multiplications, relying on the C standard guaranteeing wraparound for unsigned overflows. But with 64-bit int, uint32_t will promote to a signed int, and overflows will thus be undefined behavior. This problem already exists with uint16_t multiplications on current architectures, but moving the problem to uint32_t will cause trouble for a lot of existing code that thought using fixed-size types like uint32_t would be safe.
I chose to deal with this problem by doing a "pointless" operation to force a promotion to at least unsigned int. For example:
uint16_t x = 0xFFFF;
uint16_t y = 0xFFFF;
uint16_t z = (uint16_t)((x + 0U) * (y + 0U));
Wrong. You mentally casted each operand to int16_t before subsequently casting to int32_t. The first step is unjustified.
The correct calculation according to the C standard is: (int32_t)0xFFFF * (int32_t)0xFFFF, which definitely overflows.
That's horrifying. Why were unsigned shorts made to convert to signed ints by zero-extension, again?
> Integer promotion is the implicit conversion of a value of any integer type with rank less or equal to rank of int or of {a bit-field of type _Bool(until C23)/bool(since C23), int, signed int, unsigned int}, to the value of type int or unsigned int.
> If int can represent the entire range of values of the original type (or the range of values of the original bit-field), the value is converted to type int. Otherwise the value is converted to unsigned int.
The fact that the C/C++ integer conversion rules have these unintuitive footguns is why I made it a talking point.
Makes me wonder how ergonomic would a language with actually correct signatures for the arithmetic operators be.
+<S, M, N>: int<S, M> × int<S, N> → int<S, max(M, N)+1> // alternatively int<S, max(M, N)> × bool
-<S, M, N>: int<S, M> × int<S, N> → int<signed, max(M, N)+1> // alternatively int<signed, max(M, N)> × bool
*<S, M, N>: int<S, M> × int<S, N> → int<S, M+N>
/<S, M, N>: int<S, M> × int<S, N> → int<S, M>
%<S, M, N>: int<S, M> × int<S, N> → int<S, N>Yeah, except that multiplying two 32-bit values, recast as 64-bit signed integers, will not overflow. Even adding another 32-bit value to this product will not overflow. Throw in the final cast to uint32_t to throw away the upper sign bits, and you get the identical result.
Factually wrong. Consider: (int64_t)0xFFFFFFFF * (int64_t)0xFFFFFFFF. It definitely overflows.
>Only in C23. It was explicitly rejected for C++ 23 (and C++ 26 too, I believe).
It was added in C++20[0], see the note[1] "This is also known as two's complement representation".
[0] https://timsong-cpp.github.io/cppwp/n4868/basic.fundamental#...
[1] https://timsong-cpp.github.io/cppwp/n4868/basic.fundamental#...
Don't make me tap the sign: the majority of processors running C are weird little dirtbag chips of 16 bits or less sprinkled by the dozen.
And I bet that when you have only 16 bits of address space, you care how many bits every integer has.
Sadly, this isn't unique to micros...
Well, Microsoft has considered C done for quite some time, and after C++20, they don't seem to be in a hurry to keep up with ISO either for C or C++ (there are discussions on support channels about customer relevant C++23 and C++26 features, none on C past C17), similar to how Apple and Google are handling their in box compilers as well.
I think the only real annoyance is that each programmer/team did it with their own convention (I32, INT32, i32, int32, WORD, Word bool, BOOL, Bool, etc., etc.); standardizing helps with putting everyone on the same page more than it helps porting. It doesn't prevent people from reverse-typedef-ing standard names to local "dialectal" names, though.
But I also think that one should only rarely use raw integer types, in an ideal world; the elephant in the room is that typedef is kind of the second "billion dollars mistake" [1]. C is a weakly typed language and there's no practical way to undo it (besides transpilation), so there's double no point to leave behind raw types.
[1] For those not too familiar with C, typedef defines a "type alias", not a type: https://en.cppreference.com/cpp/language/typedef
https://github.com/gcc-mirror/gcc/blob/master/gcc/ginclude/s...
There's a simpler way to define these types in newer versions of C which have `typeof`, we can take advantage of the fact that `sizeof()` always returns a `size_t`, `ptr - ptr` always returns a `ptrdiff_t`, and a literal L'c' has type `wchar_t`, etc.
typedef typeof(sizeof(0)) size_t;
typedef typeof(nullptr) nullptr_t;
typedef typeof((void*)0-(void*)0) ptrdiff_t;
typedef typeof(L'\0') wchar_t;
typedef typeof(u8'\0') char8_t;
typedef typeof(u'\0') char16_t;
typedef typeof(U'\0') char32_t;
#define LUAI_IS32INT ((UINT_MAX >> 30) >= 3)
#define NB CHAR_BIT
#define MC ((1 << NB) - 1)
Regardless of whether you think C's flexible integer sizes are good or bad, and whether it helped propagate the language, there's no denying that if you want to write portable code across machines, you have to put in more effort compared to a language with fixed-size integers. Whether this matters or not is a matter of situation and opinion.
Other than that, I made a simulator where you can set the bit width of each integer type, and then it shows you how `x operation y` gets promoted to some output integer type. https://www.nayuki.io/page/summary-of-c-cpp-integer-rules section "Conversion rules simulator"
There should never have been a type `int` that holds a variable amount of bytes; it should have been the modern aliases like int_least32_t and int_fast32_t that actually communicate the possible size of the value.
Rust originally says that its types usize and isize are the same size as pointers, but this was ret-conned in later Rust to say actually they're the same size as addresses for this reason.
On Intel 286 we had a 16-bit machine word and 24-bit addresses. A pointer wasn't just two machine words concatenated - the upper 8 bits were stored somewhere else - a segment register.
On modern machines we don't (usually) need to consider this because we have a single linear virtual address space, though the size is architecture dependant - usually above 40 bits and below 64. Most common size is 48-bits, but also up to 57-bits with 5 level paging enabled.
Either way we round up to 64-bits to store the pointer as one integer. C optionally provides types `intptr_t` and `uintptr_t`, which are integers large enough to hold the value of a pointer. Converting a pointer to `intptr_t` and back to the pointer type results in a pointer that compares equal to the original.
However, there is no guarantee that a pointer converted to `intptr_t` and back to a pointer can be dereferenced! It works most of the time because of our linear address space and non-use of segmentation, but segmentation can still be used - the FS and GS segment registers are still available on x86_64 and are commonly used for thread local storage. If you take a `thread_local T*`, convert it to `intptr_t`, and then convert it back to a `thread_local T*` on another thread and attempt to dereference it, then despite the pointers comparing equal, they dereference to different virtual addresses.
Integers tied to the size of a pointer would have been misguided. Pointers are not integers! (They just happen to use an integer in their representation).
Another one, `size_t` is supposed to represent the maximum size of any object. However, that's also not well-defined. The maximum object size on the Intel 256 would have been 16-bits, because that is all you can fit in a single segment.
On a modern machine, a `size_t` should really be 48-bits (4LP) or 57-bits (5LP), because we can't have an object larger than our maximum virtual address size - but `size_t` is typically 64-bits.
a MISERABLE_LITTLE_PILE_OF_BITS
A `thread_local`'s actual virtual address is not merely what the pointer contains - it's an offset from some other virtual address stored in the FS or GS register (on x86-64), which is swapped when you change thread. Casting the pointer to `intptr_t` does not retain the segment base address - only the offset. The pointer is not the absolute address.
If you dereference in another thread, it's the same offset, but from a different base address.
There may be other things besides segment registers on other architectures that also make it unsafe. The C standard makes no guarantee that you can safely dereference a pointer cast from `intptr_t`.
> An integer may be converted to any pointer type. Except as previously specified, the result is implementation-defined, may not be correctly aligned, may not point to an entity of the referenced type, and can produce an indeterminate representation when stored into an object
The compiler may specify otherwise. GCC specifies that the pointer cast to integer back to pointer must point to the original object, else the behavior is undefined.
One result of this is that a fair amount of C code targeted at 68000 systems used short instead int everywhere, and then had to be subsequently updated for CPUs that preferred int32 to int16. Occasionally collateral damage can be seen from this in mysterious comments like "check if the buffer is too int."
This is the issue with how people talk about C. int is basically the signed version of size_t aka a word sized data type. It's not meant to have a fixed size.
When people want the classic 4 byte data type they should choose long instead.
It isn't. `int` is at least as large as `short` and at least 16-bits. On modern systems `int` is still typically 32-bits whereas `size_t` is typically 64-bits. There's a `ssize_t` in POSIX for signed sizes.
> When people want the classic 4 byte data type they should choose long instead.
`long` is only at least 4 bytes, and at least as large as `int`. On MSVC (LLP64 data model) it's 4 bytes, but on SYSV (LP64 data model) it's 8 bytes. `long` should almost never be used if you actually want portable code today.
`int` is 32-bits and `long long` is 64-bits on both LP64 and LLP64. If you want portable code using the native integer types, these are the ones you should use, definitely not `long`.
I am not a C developer but I used to think that there was some sanity in the design. Now that residual sanity I thought was left in C has faded away. I retract all my comments in this HN submission that defend C. Whenever anyone reads them, they should consider them made erroneously in good faith by a person who wanted to justify some of the weird decisions made in C but it turns out they were just plain silly.
Edit: actually now that I think about I'm willing to extend goodwill to C retroactively if sparkie retracts his silly nitpick and makes it charitable instead.
If you code exclusively using those types (and the `*ptr_t` ones) then you precisely express to both the compiler and the next person reading it what is supposed to be in those variables.
I can see the argument for "an int works on the natural machine size". But it starts getting a lot more complicated when you have structs - suddenly byte positions are very important (as is 'sizeof' :), and if you're running the same code on different platforms, and using pointers to access them, well you need to be careful...
Fixed-size types (and we've more or less given up on non-power-of-2 sized primitive types) force you to think about the size of the type you're using at the point of creation, and if you really do want 'an int is the size of the local machine', you're free to 'typedef u32 int;' in a platform-specific file - I deliberately did not use 'int', 'short', 'long' etc. in the language.
For this reason, platform designers were motivated to provide some 32 bit type, which by elimination needs to be int (it can't be char, which must be 8 bits, it can't be short or else you have no 16 bit type, so it must be int or long, but a 16 bit int is silly). Initial 64 bit ABIs were defined with 64 bit int types (ILP64 platforms, such as the first SPARC64 Solaris port) and the problems quickly became apparent when random C software packages failed to configure, compile, or work. Switching to LP64/LLP64 (where int is 32 bits and long is 32 resp. 64 bits) fixed this, at the cost of having to reeducate programmers to use size_t for array indexing. The decision between LP64 and LLP64 was then probably motivated by time_t, which traditionally is a long. If you do LLP64, long and thus time_t is 32 bits and you'll fall prey to the year 2036 problem. Or you use long long for time_t, breaking compatibility with ANSI C and a lot of old software. Most UNIX platforms decided to use LP64 thus, while non-UNIX platforms without this issue frequently went with LLP64 instead, reaping the benefit of staying compatible with software that assumes long is 32 bits.
These days, you probably need only three platform-dependently-sized types (as Go does):
- int/uint for array indexing; native word size, signed and unsigned - uintptr for round-tripping data pointers
uintptr needs to be different as there are a few platforms where pointers are larger than indices, for example:
- on 8086 and i286, pointers are 32 bits (segment+offset) in some code models, while indices are only 16 bits - on IBM iSeries, pointers are 128 bits, while indices are 32 or 64 bits - on capability architectures like CHERI, capabilities (pointers) are 128 bits and need special treatment, while integers are 32 or 64 bits - on MSP430X, pointers are 20 bits (!) while integers are 16 bits
Conceivably one might also need a separate type for text pointers, as these are some times of different size than data pointers (e.g. on PIC), but as arithmetic on text pointers does not generally make sense, a corresponding integer type can perhaps be omitted (use a generic function type). This also helps with platforms like PowerPC, where text pointers are pairs of addresses (entry+toc).
C's ptrdiff_t can be omitted if you follow C semantics, where differences between pointers are only meaningful within the same object, as that's just int. intptr_t does not really make a lot of sense, pointers are unsigned except on weirdo platforms (such as balanced ternary machines).
C's maxalign_t and (u)intmax_t are problematic, as they fail when the architecture is expanded with new features. For example, maxalign_t might have an 8 byte alignment on x86, but then you add SSE which requires a 16 byte alignment, AVX with a 32 byte alignment, AVX-512 with a 64 byte alignment and so on. Not good news. Same for (u)intmax_t, which end up stopping you from ever supporting larger integer types. It is not entirely clear what the solution is. For maxalign_t, perhaps the maximum alignment can be queried at runtime. For (u)intmax_t, perhaps use generic programming to instantiate the relevant code paths for the actual type used.