It was not only possible to initialize arrays like that in C89, that method is often referred to as "C89-style".

Also, let's not forget what the C standard says about integer sizes, which is that

A) It is guaranteed that sizeof char == 1

B) It is guaranteed that the following holds true: sizeof char <= sizeof short <= sizeof int <= sizeof long

So it's always completely unrealistic to assume anything about the size of these types on any system, except for the guarantee in (A)

A char might always be one byte but one byte isn't necessarily 8 bits.

I'm often puzzled by the fact that the size of basic datatypes isn't platform independent.

If I need to count to x I, more often than not, need to count to x on all platforms. Yet for some reason that is something that varies on platform.

Yes, there are of course times when this is useful but that should be the exception (right?). And apparently the industry is on my side on this by making the situation even worse and saying that an integer on a 64 bit x86-machine should be 4 bytes. Now the sizes of the datatypes not only vary by platform but they also have nothing to do with the underlying hardware architecture either. It's just some arbitrary number that is different on platforms just for the sake of giving you a headache. Thanks?

Of course a large datatype, x, might incur a severe performance penalty on platform y but just changing the size of x behind my back is not constructive.

I think the idea originally was that int would usually be the preferred "natural" size for arithmetic on any given platform. Longer sizes are available when you need greater range, and smaller sizes are available when you're trying to conserve memory, but both may be slower than int (because of the possible need for multiple-word arithmetic in the longer sizes, and the possible need for sub-word operations in the smaller sizes).

So int is for things like loop indices, where efficiency of arithmetic is more important than size in memory.