ZDoom

That's precisely why I'd prefer to use compiler-native types. They are most likely guaranteed not to conflict with anything, except for some badly behaved old libraries, which ZDoom does not use.
But the entire typedef madness that's going on is not something I consider ok.

I'd still prefer stdint.h, the C++ namespacing is something I'd rather avoid here.

As C++11 (or in fact C++14) compiler is now required, all supported build environment must have <cstdint> header. I doubt that redefining is really needed.
Or did you mean typedef's them without _t suffix? But in this case they may conflict with third party libraries or with platform specific types. You know that there is at least one system with a bunch on huge frameworks and with pretty much everything included in their header files.

Last time it got blocked because of the _t suffix. I'd still prefer the official types, though, than redefining them again for some questionable convenience. But of course this can only be done if everybody agrees and if it's done gradually, not all at once.

Graf Zahl wrote:I'd also like to replace ZDoom's homegrown sized integers with the official stdint.h types but only if there is some consensus that it is a good idea and also gradually.

Sure it's a very good idea, especially for type names like DWORD or BYTE. And no more USE_WINDOWS_DWORD workaround.

Agreed. That's how I was handling it - when I'm touching code that has NULL's I am replacing them. Changing such stuff just because can later cause problems to find when things were changed.
I'd also like to replace ZDoom's homegrown sized integers with the official stdint.h types but only if there is some consensus that it is a good idea and also gradually.

I see absolutely no reason to make a sweeping change like this just because it can be done. Yes there are advantages to using nullptr going forwards, but it's not something that can't be slowly rolled out as code is touched.

https://github.com/rheit/zdoom/pull/639

Just some C++11 stuff