Re: STL behaving improperly
Re: STL behaving improperly
- Subject: Re: STL behaving improperly
- From: Andreas Grosam <email@hidden>
- Date: Fri, 21 Oct 2005 20:10:23 +0200
On 21.10.2005, at 17:33, Cianflone, Chris wrote:
<<But I would like to emphasize, that this _ ABI issue_ has most likely
nothing to do with the original problem having runtime errors in STL. >>
We have been keeping some Xcode projects in parallel with our CodeWarrior projects since about Xcode 1.2. It wasn't until we moved to Xcode 2.0 (and 2.1), with using gcc 4, that our STL runtime errors suddenly started showing up. After having no clue what was going on I tried a sample Xcode project with some basic STL usage that worked, and started comparing compiler settings. Eventually I narrowed it down to -fshort-enums. Sure enough, even the sample project had runtime errors in STL with this setting on. Coming from CodeWarrior I had no idea that this setting would have had such a problem, especially since the Xcode project had been running successfully up until Xcode 2.0 with gcc 4.
<<This compiler option is not the default in gcc, nor in Xcode. You
shouldn't use it if you don't know what you are doing. >>
As mentioned above, I eventually figured that out the hard way. It was one little setting in a big pile of settings coming over via a imported CodeWarrior project.
If i remember rigtht, CW had the short enums per default - but i may be wrong. IMO this isn't a good idea at all since the size of the enum can't be determined easily, and code is not binary compatible anymore unless you use the same compiler with the same flags.
It's now a couple of years ago, but I know for a fact that MSL lib did crash in locale related code when the lib has been compiled with default sized enums, and client code with the switch enums_always_int on. So CW actually **has** the same "problem"! -- if you want to call it "problem". IMO, it's only naturally that it will not work.
Well, in these days there were no Itanium ABI specification and you can't blame the compiler nor the MSL - it was a programmer error. And today it's even more a programmer error when you set -fshort-enums because you break the ABI specification - deliberately or by accident. ;-)
It's only naturally that your code migth crash if you use this switch in your prorgam and include headers for libs which has been compiled without this switch.
So, be carefully when you auto convert a project from CW to Xcode. The CW product might have been compatibel with MSL, but the auto set switches for Xcode are no more compatible with the system libraries.
I would recommend to create a project per hand from scratch.
Regards
Andreas
<<To answer this, a bit more information is necessary.>>
I agree. As I pointed out in my e-mail, it was a shot in the dark.
Chris
-----Original Message-----
From: xcode-users-bounces+ccianflone=email@hidden on behalf of Andreas Grosam
Sent: Fri 10/21/2005 7:07 AM
To: xcode-Users List
Cc:
Subject: Re: STL behaving improperly
On 21.10.2005, at 08:19, Cianflone, Chris wrote:
> This is a shot in the dark since you didn't give more info about
> "failing at runtime", but I found -fshort-enums was the culprit after
> much trial and error. This had not been a problem in gcc 3, but
> became problematic in gcc 4.
Sidenote:
This compiler option is not the default in gcc, nor in Xcode. You
shouldn't use it if you don't know what you are doing. The same problem
arise when you set options which change the layout or size of structs
and classes, change the size of int, the sign of char and the size of
wchar: you change the ABI which then becomes incompatible with the
standard ABI.
This *is* the same for gcc3, or any other compiler.
But I would like to emphasize, that this _ ABI issue_ has most likely
nothing to do with the original problem having runtime errors in STL.
To answer this, a bit more information is necessary.
Regards
Andreas
> And once I discovered this, I then saw the help text in Xcode:
>
> Make enums only as large as needed for the range of possible values.
> [GCC_SHORT_ENUMS, -fshort-enums]
>
> Warning: this setting generates code that may not binary compatible
> with code generated without this setting or with Mac OS X frameworks.
>
> Chris
>
> -------------
> Chris Cianflone
> MakeMusic, Inc.
> www.makemusic.com
>
>
> -----Original Message-----
> From: xcode-users-bounces+ccianflone=email@hidden
> on behalf of Souvik Bose
> Sent: Fri 10/21/2005 12:50 AM
> To: email@hidden
> Cc:
> Subject: STL behaving improperly
>
> Hi,
>
>
>
> STL code in our XCODE project is failing at runtime whereas the same
> piece of code seems to work in other compilers especially CodeWarrior.
> Are there any known issues on this? If so, then, is there any
> workaround
> to this?
>
>
>
> Any ideas are highly appreciated.
>
>
>
> Thanks
>
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
> email@hidden
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden