Question

C code targeting x64, as has been previously discussed, should always use size_t instead of int for things like counts and array indexes.

Given that, it would arguably be simpler and less error prone to just standardize on size_t (typedef’d to something shorter) instead of int as the usual integer type across the entire code base.

Is there anything I’m missing? Assuming you don’t need signed integers, and you’re not storing large arrays of small integers (where making them 32 bits instead of 64 bits could save memory), is there any reason to use int in preference to size_t?

Answer 1

I would say in the contrary, I would prefer something where you fix the size of the integers, uint8_t … uint64_t (and sometime soon unit128_t), and these would be the base types. So you will know what you get.

And other typedef like size_t then aliasing to these. You could then simply inspect the typedef for uintprt_t and deduce your address width, e.g.

And also, people need signed types for sure.
But the relation could certainly clarified. Already now in the standard, signed types are sort of deduced from the unsigned types. This could be made explicit by forcing a prefix signed. But for sure the later wouldn’t happen, people are too much emotionally attached to int 🙂