> They might happen to be the same on your current platform. Good, and I’m not writing STL. I develop user-facing software, and I know the platforms I support.

> They might happen to be the same on your current platform. Good, and I’m not writing STL. I develop user-facing software, and I know the platforms I support. It just happened so that in the last couple of decades, all my current platforms have 32-bit integers, and I don’t expect that to change within my remaining lifetime. > It's the programmer's job to be very aware of these sorts of platform-specific points of variation. Exactly. I’m writing platform-specific code in C++, and I don’t expect compiler to interfere. When I want to abstract these things away I don’t code C++, there’re better languages out there for such requirements. > why you'd deliberately write undefined behaviour when there's no benefit to doing so. Read the comments in the link I’ve posted. Because clang authors share your opinion on the subject, I had to write a couple of pages of boilerplate code, changing ~50 C++ functions for absolutely no value. That’s one of the reasons why I prefer MSVC, by the way. > ILP64 targets exist, even if they're rare. Why should I care? As you see from this example, caring is not free, it has costs. > Additionally, using `int` as a dangerous alias for `int32_t` is not expressive when it comes to readability. Additionally, typing int is 3 keypresses, typing int32_t is 8. Given how much code I type every day, and how many integers are there in my code, the difference is not insignificant. Even Nintendo did it better on CodeWarrior toolchain, with u8, u32, u64, etc. > UB can bite you in bizarre, unpredictable, intermittent ways, especially with optimising compilers. I think you’re demonizing UB. Different cases are different. Some will crash your app right away, the worst of them will silently give incorrect results with 0.001% probability, but the code from my original comment is harmless. Also C++ compilers aren’t perfect, couple times in my career I found bugs in them. Many times, I found bugs in standard libraries or OSes. If you think writing 100% standard compliant C++ code guarantees correct programs, I have bad news for you. > Can you guarantee that you'll never change or upgrade your compiler, tweak its flags Do you have an example of specific compiler version, or flags, that will break my code above, when targeting i386, amd64 or arm32 platforms?