Hector Martin

Like, sorry, but there is *no* excuse for changing the size of core types on an established platform. That's a fucking massive ABI-breaking change. You just don't do that.

And yes I know both are 32 bits on this platform, but that doesn't mean they're freely interchangeable. And this isn't the only issue; basically every HBC release we've had where we updated libogc/devkitPro at the same time, we had to fix *some* breakage.

Well *exactly* Marcan. It doesn't mean they're freely interchangeable and the warnings you refer to are because of somebody's code being written as if they are.

You mean "everybody's". This is platform-specific code. The convention for the libogc APIs is to return s32. There's no printf specifier for s32. There is one for int32_t (if you assume *that* mapping never changes), but who uses PRId32 for every single return code?

The point is you don't just up and yank and change a core typedef out from under people without changing the platform specifier. You can argue the code makes non-portable assumptions all you want, but once a platform is defined, it's defined.

I don't believe I "yanked a core typedef" though. I fixed a problem that threw up warnings which showed up a lot of places where daft assumptions were made. Ultimately it improved a lot of code. It also brought devkitPPC in to line with other newlib based toolchains.

Running around badmouthing people behind their backs and encouraging abuse of people trying to do their best really isn't the way forward though.