Page 1 of 2

Changes to varialble types

Posted: Wed Nov 15, 2017 3:13 pm
by 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?

Re: Changes to varialble types

Posted: Thu Nov 16, 2017 2:48 pm
by 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.

Re: Changes to varialble types

Posted: Thu Nov 16, 2017 11:15 pm
by 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.

Re: Changes to varialble types

Posted: Fri Nov 17, 2017 4:53 pm
by 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.

Re: Changes to varialble types

Posted: Tue Nov 21, 2017 3:18 pm
by JoostinOnline
Could you at least tell me what release broke it? I'll want to make dual installs so I can compile old apps.

Re: Changes to varialble types

Posted: Wed Dec 06, 2017 12:55 pm
by WinterMute
JoostinOnline wrote: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.

Re: Changes to varialble types

Posted: Thu Dec 07, 2017 12:34 am
by JoostinOnline
WinterMute wrote:
JoostinOnline wrote: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.

Re: Changes to varialble types

Posted: Tue Dec 19, 2017 9:27 pm
by WinterMute
JoostinOnline wrote: 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.

Re: Changes to varialble types

Posted: Fri Dec 22, 2017 2:40 pm
by JoostinOnline
WinterMute wrote:
JoostinOnline wrote: 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.

Re: Changes to varialble types

Posted: Wed Dec 27, 2017 2:45 pm
by 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.