Is "long" still useful in C?

Question

• It's not the largest integer type anymore now that there's "long long".
• It's not a fixed-width type: It's 32 bits on some platforms and 64 on others.
• It's not necessarily the same size as a pointer (for example, on 64-bit Windows)

So, does "long" have any meaning anymore? Is there ever a reason to declare a long instead of a ptrdiff_t or int64_t?

Answer 1

Is there ever a reason to declare a long instead of a ptrdiff_t or int64_t?

There never was in those cases. If you want a pointer difference, or a specifically 64-bit value, you should be using ptrdiff_t or int64_t. You should never have been using long in the first place, except maybe behind a platform-dependent typedef.

You should use long when you need at least a 32-bit integer, because int is only guaranteed to be at least 16 bits. If you need a native type, but need at least 32-bits, use long. If the 16-bit limitation is acceptable on some old platforms (that probably don't matter and your code probably won't be compiled on ever) then it doesn't particularly matter.

Answer 2

There's a subtle difference between still useful and something you should habitually use. The long type still thrives, as Chris Lutz noted behind many system and platform specific types (though, usually as unsigned).

When you know the data you will be working with is always going to fit in that type (agreeably, better if you also know the signedness), there is no particular reason not to use it, especially if you have limited space in a structure to work with.

However, in most cases, for the sake of future maintainers, its much better to use intxx_t or uintxx_t wherever possible. For instance, you don't know that a UNIX epoch date will always fit inside an unsigned long on 32 bit platforms (hence, time_t), unless you have it on good authority that the world will end before it rolls over :)