All of them, through software implementation, as assembly programmers have done since forever.

You simply choose the integer type that your problem or task requires. If the hardware genuinely can‘t cope with it (performance), you reevaluate your requirements, define new constraints and choose new types. This is basic requirements engineering, which C only made more convoluted.

I think overall it's better to provide "natural" default types but also have had something like stdint.h. But then again mandatong even a stdint.h that early would have made writing implementations quite difficult. I think it was and is an alright tradeoff.

But it doesn't work. You use an int to hold milliseconds, it works on your machine, and when compiled for Arduino (16–bit int) it wraps around every minute.

We have stdint in modern systems so when the length of a type is a hard requirement then we can use whatever type or software emulate a larger word. Otherwise I think keeping the default types for things like eg number of elements seems alright.

So you've backtracked from most variables, to number of elements.

For number of elements there's size_t. So again, when are "natural types" the right answer?

When the C was invented? I feel it'd have been much more burdensome and inhibited the authors of various compilers if they had to write software or otherwise emulation of all these lenghths on the archs of the time. Still today I'd say, you cited size_t, I think that's the most important type, otherwise we shouldn't make most uses of integers as named fixed lengths unless we are specifically performing some mathematical operation like finite field arithmetic where the bit length matters or as you noted you know your problem size might be large enough that some archs machine words are too small. Otherwise I don't see why we shouldn't just default to natural lengths. Otherwise we need to write different int types for each arch and that doesn't sound nice unless we explicitly see a reason to.

So you write a timer app that counts in milliseconds in an int variable, and it works on your machine where that's 32 bits. I compile it for Arduino, and I can't set a timer for longer than 32 seconds in the future. Isn't that a problem? You shouldn't have used int — you should have declared a maximum time value (99:59:59) and how many bits are needed to store that value.

In what situation is plain int sufficient? If your values always fit in 16 bits, it works, but what's special about 16? A value that goes from 0 to 100 only needs 7 bits, so int is not efficient there either, you should have asked for 7 bits which would round up to 8 on most platforms. Arduino is an 8–bit platform that requires several instructions to add 16 bits to 16 bits — int isn't the most efficient type.

A ms beat in arduino sounds a bit demanding, idk how much a software based 32 bit would eat into the beats budget but I did say if we know the bounds of the problem explicitly that's a valid case for known fixed bit lengths.

The Arduino framework has a millisecond timer always running unless you turn it off.

Tbh I am finding it a bit hard to think of a use of integers that either isn't a length or a mathematical operation, so I gotta say it does narrow things down.

Bit fields? (Assuming one's not using a struct)

Good point. Yes if we need more than 8 flags we might need to consider one of the fixed length types.

Why 8? Some computers have smaller types. C has smaller types, as bitfields, but they're second–class. Why not just always specify the bits you need?

If you think 16 is probably enough and don't want to calculate, then specify 16.

The length of a type is always a hard requirement.