On Nov 1, 2011, at 2:52 PM, Andreas Färber wrote:
Am 01.11.2011 19:47, schrieb Eric Sunshine:
On Nov 1, 2011, at 12:37 PM, Andreas Färber wrote:
Am 01.11.2011 09:09, schrieb Eric Sunshine:
Perhaps the following alternative solution would be more
palatable?
It's
still tremendously ugly, but is localized to cocoa.m, thus less
intrusive.
-- >8 --
Subject: [PATCH] softfloat: Avoid uint16 type conflict on Darwin
cocoa.m includes <Security/cssmconfig.h> indirectly via
<Cocoa/Cocoa.h>.
cssmconfig.h defines type uint16 which unfortunately conflicts
with
the
definition in qemu's softfloat.h, thus resulting in compilation
failure.
To work around the problem, #define _UINT16, which informs
cssmconfig.h
that uint16 is already defined and that it should not apply its
own
definition.
Thanks for the suggestion! _UINT16 is an interesting suggestion,
however
softfloat's uint16 is not uint16_t but int, so I'd rather not do
it
that
way around.
(I had also decided against the AIX path of never defining
uint16 and
always using system definitions, since that wouldn't work
outside Cocoa
code.)
Do you have any thoughts about the include path issue? If we
could keep
QEMU code from getting into #import <Cocoa/Cocoa.h> then we could
redefine the system type instead, in cocoa.m.
Is the intention to trust uint16 from <Security/cssmconfig.h>
over the
one softfloat.h? If so, shouldn't we be taking as many type
definitions
from <Security/cssmconfig.h> as we can rather than just this one?
(I'm
not recommending it; just trying to understand the goal.)
Short-term goal: make Darwin build 1.0 without breaking others
Long-term goal: not use uint16 etc. in QEMU at all
Don't see what you mean with "taking as many type definitions".
After
uint16 I get no further conflicts for --enable-system --disable-
user,
so what is there to take?
Sorry for not being clear. My question was not about build errors but
about semantics. What I meant was that, with this patch, you are
giving
special preference only to Darwin's definition of uint16, but then
contrarily preferring softfloat's definition of int16. Likewise,
softfloat's uint32, int32, uint64, int64 from softfloat are trusted
over
the definitions from Darwin.
Other than the fact that only uint16 led to a compilation error, it
does
not make sense semantically to single out Darwin's definition of only
this one type. I would think that we should be trusting either _all_
Darwin type definitions or _none_. Singling out just this one seems
anomalous.