Also, IME it obscures bugs in your code if you're forced to overspecify things, because now someone reading it has to determine if all those explicitly specified details are actually correct or not.
Also, IME it obscures bugs in your code if you're forced to overspecify things, because now someone reading it has to determine if all those explicitly specified details are actually correct or not.
Your second point doesn't make any sense. Someone reading `int` has to determine if that is actually correct or not too.
If you assign an int32_t to an int16_t because you know the actual range of values fits at that point, later readers don't necessarily know that. (And it can change.)
If they're both int, there's no possible problem.
To put it another way:
> If they're both int32_t, there's no possible problem.
The second statement contradicts the first - int16_t is too specific and hides errors, but an arbitrary range is not?
The arbitrary range is actually capable of being correct. int16_t is almost never "correct", since it's larger than the actual range of values.
It can also be said to be an over-optimization, since on some platforms like x86 it's easier to deal with 32-bit values than 16-bit ones.
I'm not in the mood of discussing this or convincing you otherwise. If you made up your mind to use int over intWhatever_t then so be it. We're not working on the same project and I suppose you're not building anything that might kill me.