Re: Weird inline/struct offset problem
Re: Weird inline/struct offset problem
- Subject: Re: Weird inline/struct offset problem
- From: Tommy Nordgren <email@hidden>
- Date: Thu, 17 Aug 2006 16:22:32 +0200
On Aug 16, 2006, at 9:09 PM, Allen Cronce wrote:
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.
It is quite easy to replace a symbol with a new symbol, globally in
a set of source code
files. As long as the new identifier doesn't contain the new
identifier already the sementics
wont be changed by the renaming.
TextWrangler and BBEdit from www.barebones.com can both do this.
1) Search your library for the new symbol say NEWBOOL
2) Replace BOOL with NEWBOOL everywhere, if step 1) don't find it.
3)Otherwise, test with another symbol.
This should be done on your C++ library directory only.
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
_______________________________________________
------------------------------------------------------
"Home is not where you are born, but where your heart finds peace" -
Tommy Nordgren, "The dying old crone"
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