Re: [Qemu-devel] [PATCH v2 2/4] softfloat: Avoid uint16 type conflict on Darwin

["Andreas Färber" <andreas.faerber@web.de>]

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?

Andreas