From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39906 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PTmZ6-000638-9I for qemu-devel@nongnu.org; Fri, 17 Dec 2010 21:30:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PTmYs-0002to-Pd for qemu-devel@nongnu.org; Fri, 17 Dec 2010 21:30:32 -0500 Received: from mail.codesourcery.com ([38.113.113.100]:38002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PTmYs-0002t1-Gg for qemu-devel@nongnu.org; Fri, 17 Dec 2010 21:30:18 -0500 Date: Fri, 17 Dec 2010 21:30:11 -0500 From: Nathan Froyd Subject: Re: [Qemu-devel] [PATCH V2] softfloat: Rename float*_is_nan() functions to float*_is_quiet_nan() Message-ID: <20101218023011.GN25059@nightcrawler> References: <1292601366-990-1-git-send-email-peter.maydell@linaro.org> <5C19C2AC-87D5-4C9E-8D8D-E2FEC4AC89F5@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: "Edgar E. Iglesias" , Andreas =?iso-8859-1?Q?F=E4rber?= , qemu-devel@nongnu.org On Fri, Dec 17, 2010 at 11:32:03PM +0000, Peter Maydell wrote: > On 17 December 2010 17:54, Andreas Färber wrote: > > My patch does not touch the bits* types. I didn't notice any problem there. > > > > I replaced int32 by int32_t, int64 by int64_t etc. No sane code puts more > > than 32 bits into an "int32" variable, and my guests on OSX/ppc64 host still > > appeared to work. I don't have arm guests though so please check on your > > side. > > Hrm. That introduces potential semantic changes, so I'm a bit wary > of it (and my test suite is not currently comprehensive enough to be > sure of covering all of softfloat)... I'd be happier if we just renamed > the int32 & friends to some other non-clashing name, if all we're > trying to solve is a name clash issue. I wouldn't be too worried: typedef uint8_t flag; typedef uint8_t uint8; typedef int8_t int8; typedef int uint16; typedef int int16; typedef unsigned int uint32; typedef signed int int32; typedef uint64_t uint64; typedef int64_t int64; So adding _t suffixes in appropriate places should be a no-op, except for uint16/int16--and those types are never used. -Nathan