Changes to varialble types

[JoostinOnline]

I used the devkitPro updater, and now all my projects have a bunch of warnings/errors. Most of them are related to variable definitions. For example, u32 is now a long unsigned int instead of an unsigned int. Am I supposed to go through and change all my variables?

[WinterMute]

It would have been better not to use u32 if you actually meant unsigned int in the first place but, yes you're supposed to go through and fix your code.

[JoostinOnline]

It's not just my code you broke, it's almost every single homebrew app and library. None of them will compile. Why would you purposefully break compatibility after all these years? I can't see any benefit.

[angelsl]

If anyone stumbles upon this post and feels like blaming someone (which is totally pointless).. don't blame WinterMute.

Blame the author of this newlib commit.

Previously newlib defined int32_t like so:

Code: Select all

#if __STDINT_EXP(INT_MAX) == 0x7fffffffL
typedef signed int int32_t;
typedef unsigned int uint32_t;
#define __int32_t_defined 1
#elif __have_long32
typedef signed long int32_t;
typedef unsigned long uint32_t;
#define __int32_t_defined 1
#elif __STDINT_EXP(SHRT_MAX) == 0x7fffffffL
typedef signed short int32_t;
typedef unsigned short uint32_t;
#define __int32_t_defined 1
#elif __STDINT_EXP(SCHAR_MAX) == 0x7fffffffL
typedef signed char int32_t;
typedef unsigned char uint32_t;
#define __int32_t_defined 1
#endif

The first expression, of course, is true, since int is 32-bit, so it ends up being defined as signed int.

After that change, int32_t is defined as __int32_t, which is defined as:

Code: Select all

#ifdef __INT32_TYPE__
typedef __INT32_TYPE__ __int32_t;
#ifdef __UINT32_TYPE__
typedef __UINT32_TYPE__ __uint32_t;
<snip fallback, which is basically the previous block>

GCC (in both 4.8.2, the version in r27, and 6.3.0, the version in r29-1) defines __INT32_TYPE__ as long int.

Newlib should have used __INT32_TYPE__ from the start, but that's not the point here. The point is WinterMute doesn't really have a choice, unless you want to be using *really* old versions of Newlib. And yes, devkitPro does patch Newlib, but I don't think patching it for this is a good idea.

[JoostinOnline]

Could you at least tell me what release broke it? I'll want to make dual installs so I can compile old apps.

[WinterMute]

It's not just my code you broke, it's almost every single homebrew app and library. None of them will compile. Why would you purposefully break compatibility after all these years? I can't see any benefit.

Code that assumes u32/uint32_t and unsigned int are equivalent is broken, it should be fixed.

Maintaining the patch that allowed people to carry on making that assumption broke the toolchain so it was removed some considerable time ago.

[JoostinOnline]

It's not just my code you broke, it's almost every single homebrew app and library. None of them will compile. Why would you purposefully break compatibility after all these years? I can't see any benefit.

Code that assumes u32/uint32_t and unsigned int are equivalent is broken, it should be fixed.

Maintaining the patch that allowed people to carry on making that assumption broke the toolchain so it was removed some considerable time ago.

You're claiming that basically code in all apps was broken. That's nonsense. In fact, YOU were the one who defined them that way from the start. Stop trying to dodge responsibility.

[WinterMute]

You're claiming that basically code in all apps was broken. That's nonsense. In fact, YOU were the one who defined them that way from the start. Stop trying to dodge responsibility.

The underlying type of a typedef is irrelevant. You shouldn't write code that assumes u32 is anything other than u32.

[JoostinOnline]

You're claiming that basically code in all apps was broken. That's nonsense. In fact, YOU were the one who defined them that way from the start. Stop trying to dodge responsibility.

The underlying type of a typedef is irrelevant. You shouldn't write code that assumes u32 is anything other than u32.

That doesn't make any sense. You changed a bunch of typedefs, seemingly for the hell of it. You even broke every past version of libogc.

I'd heard from a few devs (including some from f0f) that you were arrogant and just assumed that if it compiled it would be fine, but I always thought it was an exaggeration. If you seriously think that everyone's code is wrong (including some of yours), there's no convincing you to fix what you broke.

[owen]

@JoostinOnline you simply have to change it or do not update. Bugs are fixed all the time, its simply how the software dev lifecycle goes. The libraries you depend on are going to go through changes. You are lucky to even have people that are willing to respond to your ignorance. Just do the updates and move on. Yes its going to take some time but everything will be better once your are done.