From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57179) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLJyu-00009v-OD for qemu-devel@nongnu.org; Tue, 01 Nov 2011 15:26:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RLJyt-0000jp-6x for qemu-devel@nongnu.org; Tue, 01 Nov 2011 15:26:44 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:52010) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLJys-0000jd-SX for qemu-devel@nongnu.org; Tue, 01 Nov 2011 15:26:43 -0400 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate03.web.de (Postfix) with ESMTP id A44FA1A971EAD for ; Tue, 1 Nov 2011 20:26:41 +0100 (CET) Message-ID: <4EB0479C.9070307@web.de> Date: Tue, 01 Nov 2011 20:25:16 +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> In-Reply-To: <72FFEFE7-437A-4B1E-86FE-4169B4EE50CA@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:06, schrieb Eric Sunshine: >=20 > On Nov 1, 2011, at 2:52 PM, Andreas F=E4rber wrote: >=20 >> 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 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 indirectly via >>>>> . >>>>> 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 an= d >>>> always using system definitions, since that wouldn't work outside Co= coa >>>> code.) >>>> >>>> Do you have any thoughts about the include path issue? If we could k= eep >>>> 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 th= e >>> one softfloat.h? If so, shouldn't we be taking as many type definitio= ns >>> 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". After >> uint16 I get no further conflicts for --enable-system --disable-user, >> so what is there to take? >=20 > 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 ove= r > the definitions from Darwin. >=20 > Other than the fact that only uint16 led to a compilation error, it doe= s > 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 just push my version of preference. 2) We disagree on the solution, so I'm fair and send a pull request for the three other non-controversial patches only and 1.0 remains broken on Darwin. 3) You send a patch based on this one, detailing what additional changes you suggest and we'll see clearer what exactly you mean. I'm not preferring any definition of int16, uint32, etc., there simply is no conflict, so why would I clutter softfloat.h with unnecessary workarounds that we want to go away anyway. Feel free to refactor fpu/* instead to not use uint16 in the first place. I did so once and it was rejected, so I'm not too inclined to do that again unless we decide on how exactly to proceed with that! Andreas