Article posted on: 2023-04-28 23:31
Last edited on: 2023-04-28 23:41
Written by: Sylvain Gauthier

There is nothing wrong with variable width types in C

I recently stumbled upon a blog article that was basically saying “stop using variable width types in C”, meaning int, long int, unsigned int, char etc. The argument was so idiotic that frankly, I need to blog about it to sleep better at night.

The argument was essentially that “when using int, you need a separate branch for 16 and 32 bits thus increasing complexity of the code”. Let’s unpack this.

First, in 99% of the cases, there are really only four integer values I’m ever interested in: 0, 1, many and “as much as possible”. The first three are almost always covered by int whether it’s 16 or 32 bits, the last one is long long int.

Second, the exact maximum value that I can fit in an int is completely irrelevant: its name is INT_MAX and all I need to know is that if the addition of two int would be greater than that, I’d have an undefined behaviour on my hands. Whether INT_MAX is 65536 or 4294967296 or 0xDEADBEEF is not my problem. You should always check your int additions and multiplications for overflows against INT_MAX anyway, if you really care about correctness.

Third, by that logic, if you were to re-implement strchr, you’d also have one code path per possible input length, if you are going to do branches for every possible maximum value of such and such type… Here is my understanding of what the author of this article is doing:

if (INT_MAX == 65536) {
    /* oh no I'm on a 16 bit int machine, I'm literally crying right now */
} else if (INT_MAX == 4294967296) {
    /* pheww I'm on a normal computer */
} else if (INT_MAX == 0xDEADBEEF) {
    /* what the fuck?! */
} else {
    /* etc */

So yeah, this is keeping me up at night.

That is not to say to never use fixed types, there are plenty of cases where they are actually useful. But simply dismissing variable width types altogether is silly, especially when you back it up with dumb arguments like “more code paths/complexity”.