Changes to varialble types

JoostinOnline
Posts: 18
Joined: Fri Apr 27, 2012 6:05 am
Location: The Twilight Zone
Contact:

Changes to varialble types

Post by JoostinOnline » Wed Nov 15, 2017 3:13 pm

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
Site Admin
Posts: 1404
Joined: Tue Aug 09, 2005 3:21 am
Location: UK
Contact:

Re: Changes to varialble types

Post by WinterMute » Thu Nov 16, 2017 2:48 pm

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.
Help keep devkitPro toolchains free, Donate today

devkitPro IRC support
Personal Blog

JoostinOnline
Posts: 18
Joined: Fri Apr 27, 2012 6:05 am
Location: The Twilight Zone
Contact:

Re: Changes to varialble types

Post by JoostinOnline » Thu Nov 16, 2017 11:15 pm

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
Posts: 1
Joined: Fri Nov 17, 2017 4:45 pm

Re: Changes to varialble types

Post by angelsl » Fri Nov 17, 2017 4:53 pm

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
Posts: 18
Joined: Fri Apr 27, 2012 6:05 am
Location: The Twilight Zone
Contact:

Re: Changes to varialble types

Post by JoostinOnline » Tue Nov 21, 2017 3:18 pm

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

WinterMute
Site Admin
Posts: 1404
Joined: Tue Aug 09, 2005 3:21 am
Location: UK
Contact:

Re: Changes to varialble types

Post by WinterMute » Wed Dec 06, 2017 12:55 pm

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.
Help keep devkitPro toolchains free, Donate today

devkitPro IRC support
Personal Blog

JoostinOnline
Posts: 18
Joined: Fri Apr 27, 2012 6:05 am
Location: The Twilight Zone
Contact:

Re: Changes to varialble types

Post by JoostinOnline » Thu Dec 07, 2017 12:34 am

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.

WinterMute
Site Admin
Posts: 1404
Joined: Tue Aug 09, 2005 3:21 am
Location: UK
Contact:

Re: Changes to varialble types

Post by WinterMute » Tue Dec 19, 2017 9:27 pm

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.
Help keep devkitPro toolchains free, Donate today

devkitPro IRC support
Personal Blog

JoostinOnline
Posts: 18
Joined: Fri Apr 27, 2012 6:05 am
Location: The Twilight Zone
Contact:

Re: Changes to varialble types

Post by JoostinOnline » Fri Dec 22, 2017 2:40 pm

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.

owen
Posts: 13
Joined: Mon Feb 07, 2011 2:05 pm
Contact:

Re: Changes to varialble types

Post by owen » Wed Dec 27, 2017 2:45 pm

@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.

Post Reply

Who is online

Users browsing this forum: No registered users and 7 guests