The lack of specified type sizes is something that bit me recently. On pretty much every x86-64 C/C++ compiler, sizeof(long) is 8, except on MSVC where it's 4. Thank goodness for explicitly sized, now-standard types like int64_t.
And if that colleague won't learn, that sounds like an issue in need of a bit of active management...
Once an idea enters his head it's hard to dislodge it. He learned programming from a mediocre CS school (despite the expensive price tag, which they deserve for their medical and law schools, not their engineering disciplines). And when something works, it's hard to convince him that it's wrong (that is, correct by coincidence) or unstable (in this case, sizeof(int) and related issues). He isn't technically (one of his favorite words) wrong in many instances, but problems will arise when we change OS, compiler, or CPU.
I'm slowly converting him to seeing things my way. My main contribution has been to mentor the junior developers. Things will change as their contributions worm their way into our projects.
Maybe I was just too ignorant and was limiting myself to what Turbo C had to offer on the MS-DOS side.
Of course on Windows we had all those WORD, DWORD, BYTE, BOOL,... macros already, but I was only thinking about actual C standard bit-width types.
Not really "64 bit" tho-on IBMi pointers are 16 bytes with teraspace enabled.
sizeof(int) >= 2
sizeof(long) >= sizeof(int)
That's all you can expect.
The best approach is still to not expect anything.
§5.2.4.2.1
CHAR_BIT is at least 8
USHRT_MAX is at least 2^16 - 1
UINT_MAX is at least 2^16 - 1
ULONG_MAX is at least 2^32 - 1
ULLONG_MAX is at least 2^64 - 1
§6.2.5p8 guarantees that integers of increasing conversion ranks obeys subset relations, and §6.3.1.1 lays out that short, int, and long have conversion ranks in that order.
Thus, sizeof(char) = 1 ≤ sizeof(short) ≤ sizeof(int) ≤ sizeof(long) ≤ sizeof(long long).