Weird inline/struct offset problem
Weird inline/struct offset problem
- Subject: Weird inline/struct offset problem
- From: Allen Cronce <email@hidden>
- Date: Wed, 16 Aug 2006 12:09:46 -0700
Hi all,
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'.
This library has caused problems for us when used with Cocoa, because
'BOOL' is defined as an unsigned char in Objective C land. Sometimes
this results in link errors due to signature differences. And sometimes
get crashes and other bad behavior because of a mismatch of
struct/object element offsets between C++ and objective C.
In the past we've worked around this problem by substituting BOOL for
BOOLEAN, which is another type that is under our control. But we've only
done this substitution on objects that are visible to our Objective C
applications. Kind of a cop out, but we've been a little gun shy of
making massive changes to the legacy library.
I'm currently porting a Cocoa app, that requires the legacy library,
from CW to Xcode 2.4. But I'm seeing something really weird.
Basically inline methods for objects defined in the legacy library that
have BOOL members are demonstrating an offset mismatch. That is, a given
object can successfully access a member variable downstream of a BOOL
member variable. But an inline method that references the same member
gets the wrong offset.
I would expect that to happen if the inline was called from Objective C
because if it was truly inlined, it would have a different definition
for BOOL. But it's also happening when an inline is referenced only in
the legacy library itself, which should have a consistent idea of how
BOOL is defined. Note that this is happening in the debug build with no
optimization, and with DWARF symbols.
What seems to be happening is that all inlines, even those that are only
used in the legacy library, are using Objective C's idea of BOOL instead
of the legacy library's BOOL. Maybe this has something to do with Xcode
2.4's new ability to step into inline functions?
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.
I looked into redefining BOOL for the Mac build, but that was
problematic due to some type checking that we depend in the legacy
library. I guess the real solution here is to gut our legacy library of
its BOOL use. But it's a huge library, so that direction is not without
risk.
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.
Any thoughts or suggestions would be welcome.
Best,
--
Allen Cronce
_______________________________________________
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