Re: Weird inline/struct offset problem
Re: Weird inline/struct offset problem
- Subject: Re: Weird inline/struct offset problem
- From: Allen Cronce <email@hidden>
- Date: Wed, 16 Aug 2006 18:46:42 -0700
Hi Eric,
Thanks for getting back to me. Yes, I was aware that 'bool' is a single
byte on Intel. That issue came up when we went Universal a while back.
So we dealt with it then.
I fact, my suspicion is that the problem I'm seeing only happens on PPC
because of the size difference between our library's BOOL and Objective
C's. The Intel variant of the same application probably just works
because our BOOL (which is a bool) and Objective C's BOOL (which is an
unsigned char) are the same size.
But what's really inexplicable about this is the fact that inlined code
in our library has a different idea of the BOOL size than the regular
compiled code from the same library. It's as if the inlined code in the
library is being affected at link time by the target Cocoa application.
Just as another data point, this problem only happens in the debug
build. It doesn't happen in release.
So I suspect that this is an Xcode 2.4 bug, possibly related to recent
changes that allow breakpoints and stepping in inline code.
Incidentally, I agree with your take on types below. Unfortunately we're
stuck with our legacy library as is. So we have to deal with our own
ancient type selection, as well as those of Windows and Next.
Best,
--
Allen Cronce
Eric Albert wrote:
> While I don't have a solution for the problems you've described, I do
> have a few comments....
>
> On Aug 16, 2006, at 12:09 PM, Allen Cronce wrote:
>
>> We've got a cross platform, legacy C++ static library that uses a 'BOOL'
>> type. For Windows, this is a standard type defined as an int. For Mac,
>> we define it as a 'bool'.
>
> 'BOOL' unfortunately is not the same as 'bool' on the Mac. On
> PowerPC, 'bool' is four bytes, but BOOL is an unsigned char. On
> Intel, 'bool' is one byte, but I can't remember if it's signed or
> unsigned.
>
>> As far as working around the problem, I suppose I could try using the
>> "Use One Byte 'bool'" option. That would automatically match our legacy
>> library's BOOL definition to the same size as Objective C. But the rub
>> is that "bool" is used something like 12,000 times in the system
>> frameworks, so there's lots of opportunity for our binary to "disagree"
>> with the frameworks.
>
> Keep in mind that this is the default for Intel (and there's no flag
> to change it to four bytes), so you'll have to be able to work with
> one-byte bools to be able to run on Intel.
>
>> I really wish that Apple (or rather Next) had never redefined the
>> Windows BOOL type. It's been a big pain and a drag on our ability to use
>> Objective C.
>
> For what it's worth, we don't have much control over the types
> Microsoft chooses. It would've been better all around if both
> Microsoft and NeXT had chosen types defined in the C standard, much as
> it's often better today to use C99's fixed-size types like uint32_t.
>
> -Eric
>
>
_______________________________________________
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