From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43930) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLKrL-0005w4-Cw for qemu-devel@nongnu.org; Tue, 01 Nov 2011 16:23:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RLKrJ-0004LL-Tx for qemu-devel@nongnu.org; Tue, 01 Nov 2011 16:22:59 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:56593) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLKrJ-0004LC-I1 for qemu-devel@nongnu.org; Tue, 01 Nov 2011 16:22:57 -0400 Received: from moweb001.kundenserver.de (moweb001.kundenserver.de [172.19.20.114]) by fmmailgate01.web.de (Postfix) with ESMTP id 21E041A2D1DCB for ; Tue, 1 Nov 2011 21:22:56 +0100 (CET) Message-ID: <4EB054C5.2080502@web.de> Date: Tue, 01 Nov 2011 21:21:25 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1320088682-12958-1-git-send-email-andreas.faerber@web.de> <1320088682-12958-3-git-send-email-andreas.faerber@web.de> <47C91597-B6B1-4351-9DC3-30E405EC480B@sunshineco.com> <4EB0202E.50701@web.de> <20B88770-C260-4A2F-8E85-B84493675F10@sunshineco.com> <4EB03FE9.7090007@web.de> <72FFEFE7-437A-4B1E-86FE-4169B4EE50CA@sunshineco.com> <4EB0479C.9070307@web.de> <5C954CC3-E437-4658-A6C9-AD9224E2E2F3@sunshineco.com> In-Reply-To: <5C954CC3-E437-4658-A6C9-AD9224E2E2F3@sunshineco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 2/4] softfloat: Avoid uint16 type conflict on Darwin List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Sunshine Cc: Peter Maydell , Juan Pineda , qemu-devel@nongnu.org Am 01.11.2011 20:45, schrieb Eric Sunshine: > On Nov 1, 2011, at 3:25 PM, Andreas F=E4rber wrote: >> Am 01.11.2011 20:06, schrieb Eric Sunshine: >>> >>> On Nov 1, 2011, at 2:52 PM, Andreas F=E4rber wrote: >>> >>>> Am 01.11.2011 19:47, schrieb Eric Sunshine: >>>>> On Nov 1, 2011, at 12:37 PM, Andreas F=E4rber wrote: >>>>>> Am 01.11.2011 09:09, schrieb Eric Sunshine: >>>>>>> Perhaps the following alternative solution would be more palatabl= e? >>>>>>> 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 indirectly via >>>>>>> . >>>>>>> cssmconfig.h defines type uint16 which unfortunately conflicts wi= th >>>>>>> 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 o= wn >>>>>>> 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 i= t >>>>>> 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 then we could >>>>>> redefine the system type instead, in cocoa.m. >>>>> >>>>> Is the intention to trust uint16 from over = the >>>>> one softfloat.h? If so, shouldn't we be taking as many type >>>>> definitions >>>>> from 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". Afte= r >>>> 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 givi= ng >>> 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 o= ver >>> the definitions from Darwin. >>> >>> Other than the fact that only uint16 led to a compilation error, it d= oes >>> 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. >> >> Listen, I dont have time for this. We have three options: >> >> 1) I can say, "I'm the Cocoa maintainer for multiple years now, I don'= t >> care if someone pops up day before the deadline and complains" and jus= t >> push my version of preference. >=20 > I hope that you do not interpret my alternate patch as a "complaint > before the deadline". Not your patch, I thanked you for it, but the seemingly nonconstructive complaints about my follow-up. I would've much preferred code. :/ > My intention only was to be helpful when I saw > Peter's response [1], and thought that a less intrusive patch might be > more acceptable. >=20 > [1]: http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg03936.h= tml Then it's not the intention we differ in, I had tried some solutions inside ui/cocoa.m myself before. Apart from non-intrusiveness further criteria are reversibility of the short-term fix[1] and ABI safety. I'll happily review new patches from tomorrow on. Regards, Andreas [1] We have similar lurking issues with [u]int* on Haiku/BeOS.