> Actually, after working on this I got a report mentioning that my changes to move from imprecise-width to precise-width types fixed a security issue. This made me realize that more existing issues could still be fixed this way, and I started fixing other ones reported via ClusterFuzz after that.<p>The author found a security issue simply because the conversion required a careful code review. The security issue didn't stem from using native integer types. In fact, I'd argue that the security issue stemmed from the original programmer making the kind of assumptions that are typical when you have the mindset of fixed-width types. To avoid multiplicative overflow they used an intermediate type that was twice the width. And in fact this aspect of it was correct. What was broken was their logic for detecting overflow of a second multiplication operation. Using fixed-width types wouldn't have fixed that issue. The actual fix simply used base::CheckedNumeric as the type, which checks overflow in a library via operator overloading. The underlying type is irrelevant, though it's not clear to me why they ended up choosing int32_t for the template type given that the function argument parameters are still unsigned int. That suggests some hidden dependencies and assumptions on callers that remain undeclared.<p>Nowhere did this author show an example of why switching from native types to fixed-width types improved anything. It's unsurprising that a bug was discovered as a result of doing a careful, focused code review. If they had switched their focus from changing types to instead reviewing all multiplication operations, I bet they'd have found many more bugs. Also, what we don't know is if the conversions introduced any issues as it could take years for those to shake out, if at all.