Agreed on both points. Plain int hasn't been very good for a long time. C99 <stdint.h> is really the way to go, but since this is C++ we're talking about, both the C++ committee and Microsoft Visual Studio deserve most of the blame for why people weren't using them since neither recognized/supported it for the longest time. (Visual Studio just finally got stdint and stdbool, about 15 years late.)
Visual Studio has had stdint.h since its 2010 edition. Before that there were readily-available substitutes (like https://code.google.com/p/msinttypes/), or you could do it yourself by typedef'ing [unsigned] __intNN as [u]intNN_t.
But not stdbool, nor a lot of other C99-ish features until Visual Studio 2013 Update 4 which shipped this past November. 10 or 15 years too long makes little difference. Way too long over due.
Somebody elsewhere pointed out to me that these will give types that are not aliases of the common ones. I.e. __int8 isn't the same as either unsigned char or char. Probably won't make a difference most places, but what does?
That is also the case in usual implementations of stdint.h, where int8_t is defined to be `signed char`. In C and C++, `char`, `signed char`, and `unsigned char` are different types, and `char` is not guaranteed to be signed or unsigned---that's up to the implementation.
EDIT: looking at the documentation, it appears that __int8 is supposed to always be an alias for `char`, even as far back as 2003: https://msdn.microsoft.com/en-us/library/29dh1w7z(v=vs.71).a.... However, the workaround found in msinttypes suggests that Visual Studio 6 does have this problem. I weep for those still using it.
It's not been a problem (for a long time now) to find appropriate headers that typedef'd fixed size types (int32_t etc.) for almost any platform you would care about. For any reasonably complicated cross-platform codebase, it's not so much effort to include such a header in your code for the sake of improving the readability and debuggability of your code by a lot.
A lot of people know to do this, but I have met a shocking amount of C++ developers that know nothing of <stdint.h>.
And here we have a prime example of Chrome, a major cross-platform project with high visibility that is not using these types nor didn't define their own in this case. These types were intended to help reduce mistakes. But compiler fragmentation basically resulted in organizations avoiding it, leading to these types of mistakes that could have been avoided in the first place.
I work with a MSVC guy who not only didn't know about stdint, but also thought/thinks that 'word' means 16 bits, and insists that the WORD typedef is more portable than uint16_t.
Still, at least nowadays there is no excuse -- everything from TI to VC++ supports stdint variations.
Maybe I'm reading this wrong, but to me it seems like this is saying go ahead and use the fixed size variants whenever, but it is still OK to use int when you need <=32 bits.
Yeah it's al lukewarm endorsement of int, quite possibly there only to accommodate legacy code.
"<stdint.h> defines types like int16_t, uint32_t, int64_t, etc. You should always use those in preference to short, unsigned long long and the like, when you need a guarantee on the size of an integer. Of the C integer types, only int should be used."
And agreed, good catch.