> A 'plain' int object has the natural size suggested by the architecture of the execution environment.<p>Shouldn't they be 64 bits on most modern systems then?
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.<p>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.<p>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.
Good article.<p>C would probably not have survived unless it had this flexibility.<p>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.<p><edit> I didnt see the footnote about DSPs at first read </edit>
But not having fixed size integers (or integers tied to the size of a pointer) was. Both can be useful
Author here. Thanks for sharing.