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 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.