View unanswered posts | View active topics It is currently Thu Dec 14, 2017 9:11 am



Reply to topic  [ 7 posts ] 
 Changes to varialble types 
Author Message

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


Wed Nov 15, 2017 3:13 pm
Profile WWW
Site Admin

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


Thu Nov 16, 2017 2:48 pm
Profile ICQ WWW

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


Thu Nov 16, 2017 11:15 pm
Profile WWW

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


Fri Nov 17, 2017 4:53 pm
Profile

Joined: Fri Apr 27, 2012 6:05 am
Posts: 16
Location: The Twilight Zone
Could you at least tell me what release broke it? I'll want to make dual installs so I can compile old apps.


Tue Nov 21, 2017 3:18 pm
Profile WWW
Site Admin

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


Wed Dec 06, 2017 12:55 pm
Profile ICQ WWW

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


Thu Dec 07, 2017 12:34 am
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 7 posts ] 

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.
Get devkitPro at SourceForge.net. Fast, secure and Free Open Source software downloads