Rendered at 15:44:24 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
adrian_b 6 hours ago [-]
I agree that the C flexible integer sizes were still necessary at the time of its creation, when some important computers still had word sizes that were not powers of two.
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.
nickcw 5 hours ago [-]
The fixed size int types int32_t and friends weren't introduced until C99. Microsoft held out until 2013 before it put <inttypes.h> into Visual Studio!
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.
ddlsmurf 5 hours ago [-]
I would agree if overflow on those types wasn't undefined behaviour, or unpredictable
jibal 5 hours ago [-]
Per the C standard `sizeof(char)` is always 1, regardless of how many bits it has.
ddlsmurf 5 hours ago [-]
because it's the unit of addressable memory that C is concerned by with sizeof, otherwise its values still depend on CHAR_BIT
locknitpicker 6 hours ago [-]
> At that time, 36 years ago, the C flexible integer sizes were already obsolete.
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.
flohofwoe 6 hours ago [-]
The parent is completely right in the sense that for actually portable C code it was always better to use fixed-width integer types which were chosen for the problem to solve instead of target hardware capabilities.
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.
locknitpicker 4 hours ago [-]
> The parent is completely right in the sense that for actually portable C code it was always better to use fixed-width integer types which were chosen for the problem to solve instead of target hardware capabilities.
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?
adrian_b 6 hours ago [-]
As I have said, I have not worked with a single architecture.
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.
stkdump 2 hours ago [-]
The problem begins when you start mixing the traditional types and (u)intN_t, because the latter are merely aliases for the internal types, and it messes up overload resolution. All relevant platforms have pretty much agreed the size of char, short (int), int and long long (int). They have different opinions about long (int) and thus an int64_t might use either long (int) or long long (int).
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.
flowerbreeze 7 hours ago [-]
Thank you for the article! Do I see a Turbo-C screenshot there or am I imagining it? It was my first IDE (I didn't know that's what it was called) when I started programming. I sometimes miss it, it was really good, especially the help system.
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.
quelsolaar 7 hours ago [-]
Good article.
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>
adrian_b 5 hours ago [-]
This kind of flexibility is a purely historical thing.
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.
pjmlp 6 hours ago [-]
C survived because UNIX carried it.
6 hours ago [-]
flohofwoe 6 hours ago [-]
I don't agree. UNIX was an extremely niche operating system until Linux won the data center, at that time both C and C++ were already extremely popular outside the UNIX world. C won because it was so easy to adapt to new hardware architectures (even GPU shading languages are just minimally extended flavours of C and C++).
pjmlp 5 hours ago [-]
Most people only cared about C, because they needed to work on UNIX, and UNIX was taking over the server room and all 1980's graphical workstations.
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.
imtringued 5 hours ago [-]
Disclaimer: This is just some cursory research using LLMs.
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.
flohofwoe 5 hours ago [-]
My point is that C's popularity quickly outgrew the popularity of UNIX, especially during most of the 1990s before Linux made UNIX accessible to us "PC peasants". Most 1990s PC games were written in C, and C was also the dominant high level language on 16/32 bitters like the Amiga or Atari ST.
pjmlp 2 hours ago [-]
Nope, they were mostly written in Assembly.
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.
flohofwoe 2 hours ago [-]
> Nope, they were mostly written in Assembly.
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).
prerok 6 hours ago [-]
Sorry, what? Most of data centers were running a UNIX operating system back in the day. What operating system do you think they were running?
tialaramex 5 hours ago [-]
There is a weird moment toward the end of the 1990s when Microsoft is trying to show their NT is a serious competitor in this space.
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.
pjmlp 2 hours ago [-]
Yeah, and one of the ways to show it was a serious OS for DoD projects was to have a POSIX subsystem, which had they kept it around, Linux would never have taken off on the PC, and there would be no need for WSL 40 years later.
tialaramex 2 hours ago [-]
The POSIX subsystem is a box checking exercise. The reason the box was there isn't satisfied but the box was checked and Microsoft hoped that's good enough. If you need "a Unix" and they give you NT and circle the stuff about POSIX you don't go "Oh, perfect" you ask them to fix the requirements document so that you can have an actual Unix next time.
WSL is Redmond going OK yeah, here you go, an actual Unix.
fragmede 5 hours ago [-]
WindowsNT was the other operating system of that time.
prerok 1 hours ago [-]
That's way way later. UNIXes were the ones running in 70s and 80s. WindowsNT and Linux only later came to take a slice and, still later on, Linux won the day. How anyone would consider UNIX "niche" is beyond me.
pjmlp 2 hours ago [-]
With Win32, OS/2 and POSIX subsystems.
imtringued 5 hours ago [-]
Not sure why you would need to invent an new programming language when we're still strictly talking about data types. You just introduce a new data type for the hardware if that's what's necessary. You don't need a whole language.
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.
usrnm 7 hours ago [-]
But not having fixed size integers (or integers tied to the size of a pointer) was. Both can be useful
sparkie 6 hours ago [-]
What is the size of a pointer though?
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.
7 hours ago [-]
tialaramex 6 hours ago [-]
It turns out that you don't want integers the same size as a pointer because somebody might squirrel away capability bits in your pointer type (see CHERI) and you definitely do not want integers with capability bits.
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.
quelsolaar 7 hours ago [-]
At the time its was probably very hard to know what the fixed sizes should be.
pjmlp 6 hours ago [-]
PL/I among other systems languages predating C, had the ability to explicitly define bit sizes for its types.
RobotToaster 7 hours ago [-]
> A 'plain' int object has the natural size suggested by the architecture of the execution environment.
Shouldn't they be 64 bits on most modern systems then?
userbinator 6 hours ago [-]
On x86-64, you need an extra prefix to do 64-bit operations (while 64-bit addressing is the default), so it's a question of "are you sure you need the 64 bits and 32 isn't enough?"
entrope 6 hours ago [-]
> Shouldn't they be 64 bits on most modern systems then?
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 .
imtringued 5 hours ago [-]
char is at least 8 bits, short is at least 16 bits, long is at least 32 bits, long long is at least 64 bits.
Not sure how what you said makes sense.
entrope 4 hours ago [-]
[dead]
flohofwoe 7 hours ago [-]
It should indeed, and in hindsight it would have been better to move int to 64 bits (especially for C's integer promotion, which only really makes sense when the promotion happens to the register width.
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.
astrobe_ 6 hours ago [-]
I've always believed that they kept 32 bits ints on 64 bits CPU as a default because going full 64 bits would make the code and data structures bigger for "no reason" (it's not often that one hits the 4.10^9 limit in system code (if you don't count timestamps, that is)). For instance, a load-register-with-immediate instruction would normally take 5 bytes (opcode+value) on 32 bits, but 9 bytes on 64.
sparkie 4 hours ago [-]
I think backward compatibility was the main aim. Intel tried redesigning the architecture as 64-bit native (Itanium), but AMD done a better job at backward compatibility - and intel eventually adopted it as x86-64.
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.
Alpha3031 6 hours ago [-]
Memory addresses being 64 bits due to needing to address more than 4 GiB memory doesn't mean most integer instructions operate most efficiently with 64 bits. Instructions for 32 bit integers are still more efficient than 64 bit, whereas 16 bit operands require a prefix byte meaning they're less compact and cache efficient (on AMD64 anyway).
pjmlp 6 hours ago [-]
Kind of, the mistake was not doing like PL/I where besides default machine specific sizes, the developer could explicitly assert the required sizes.
astrobe_ 6 hours ago [-]
Is that really that much of a big deal, though? Before stdint, if one needed that level of accuracy, one would do your own equivalent of stdinit by hand, and adjust those definitions when porting to another compiler/platform. The same goes for your local boolean type.
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.
The deal was dealing with #ifdef spaghetti to define all of those, especially when mixing libraries across platforms.
flohofwoe 6 hours ago [-]
C99 kinda fixed that with the `(u)int_leastN_t` types (which are hardly used in practice though). And shame that it took Microsoft 16 years to even start supporting C99 though so we were basically forced to keep using our own custom integer typedefs long after the C standard had fixed the issue.
pjmlp 5 hours ago [-]
Agreed, but it could have been there since day one, given the languages in 1960's.
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.
Alpha3031 6 hours ago [-]
I thought most implementations of C have stdint (intN_t, leastN_t and fastN_t etc).
flohofwoe 6 hours ago [-]
These are C99 features which MSVC only got around 2015 (of course a decade later those are safe to use in portable code).
adastra22 6 hours ago [-]
No one thinks that ptrdiff_t should be a fixed size. It is quite obviously the integer type you would get from subtracting two pointers, which is naturally tied to the word size of the machine you are using. C's original "int" type is what we would now call ptrdiff_t.
gustavopezzi 24 hours ago [-]
Author here. Thanks for sharing.
7 hours ago [-]
spacedcowboy 5 hours ago [-]
So, writing xc [1], I took the opposite approach, but the real reason for that was more cross-platform compatibility - xc compiles for Mac(M series), Win64, Linux (x86_64), iOS, Android, WASM, m68k, Arm A9, and 6502. The basic types in xc are spelt {u,i}{8,16,32,64} and since the platforms covered range through 8-, 16-, 32- and 64-bit machines, being explicit about the size of the data-structure was a lot more useful than it being implied.
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.
I feel like the article glosses over the fact that (to my mind) `int_fast32_t` and `int_least32_t` are a much better solution than "int is a random size good luck"
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.
mmoll 6 hours ago [-]
I came here to say exactly that. There’s int_leastN_t for storage and int_fastN_t for computation. Stdint.h really gets a bad rap here.
lexicality 6 hours ago [-]
fwiw depending on use cases you might actually want to be using the fast variants for storage too, for example on arm64 you'll get aligned memory loads
lmz 6 hours ago [-]
Meh. In today's world if exact sizes were not a requirement then you should use the int_fastN_t types to at least guarantee the width you are expecting instead of using the fixed size types (which may not be optimal) or using plain "int" which may be smaller than expected.
imtringued 5 hours ago [-]
>This is a deliberate design statement. int was never meant to be "32 bits". It meant "whatever this machine is fastest and most comfortable with".
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.
sparkie 5 hours ago [-]
> int is basically the signed version of size_t aka a word sized data type. It's not meant to have a fixed size.
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`.
imtringued 5 hours ago [-]
Great now you made C look stupid again.
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.
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.
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.
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?
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 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.
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.
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>
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.
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.
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).
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.
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.
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.
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.
Shouldn't they be 64 bits on most modern systems then?
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.
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.
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
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 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.
[1] https://compile-xc.org/compiler/language/types/
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.
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.