From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53121 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OlSqk-0000Hn-FJ for qemu-devel@nongnu.org; Tue, 17 Aug 2010 16:33:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OlSqj-00032R-A8 for qemu-devel@nongnu.org; Tue, 17 Aug 2010 16:33:34 -0400 Received: from fe02x03-cgp.akado.ru ([77.232.31.165]:54776 helo=akado.ru) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OlSqj-00031y-3P for qemu-devel@nongnu.org; Tue, 17 Aug 2010 16:33:33 -0400 Date: Wed, 18 Aug 2010 00:33:05 +0400 (MSD) From: malc Subject: Re: [Qemu-devel] [PATCH 2/5] CODING_STYLE: add C type rules In-Reply-To: <4C6AE665.7090502@redhat.com> Message-ID: References: <4C6A43B5.40809@redhat.com> <4C6AE1AA.7000200@redhat.com> <4C6AE665.7090502@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jes Sorensen Cc: Blue Swirl , qemu-devel On Tue, 17 Aug 2010, Jes Sorensen wrote: > On 08/17/10 21:24, malc wrote: > > On Tue, 17 Aug 2010, Jes Sorensen wrote: > > > >> On 08/17/10 20:55, malc wrote: > >>> On Tue, 17 Aug 2010, Blue Swirl wrote: > >>>>> The other thing that might be worth mentioning in the int/long section > >>>>> is that long is complicated in broken development environments such as > >>>>> Windows where it is only 32 bit :( > >>> > >>> There's absolutely nothing broken about LLP64 it's as valid as any other > >>> ABI. (That's to Jes) > >> > >> Well it works if you program for it, but it still doesn't make it any > >> good when you can't keep a pointer in a long to apply arithmetic to it. > >> Anyway point with the documentation is to make it clear that we rely on > >> being able to do long foo = (long)ptr; > > > > Which isn't (and never was) sanctioned by any standard, IOW not good. > > Well maybe this is where the problem is. Not being able to do this means > that we need a special integer type to cover this case if we wanted to > work on win64. Switching to long long would generate bad code on 32 bit > archs so thats not an option. That's why [u]intptr_t was invented. > > Depending on your viewpoint it is either it not being a standard that is > bad, or the LLP64 that is bad. This doesn't really parse for me. > > Anyway this is personal preference. > > Jes > -- mailto:av1474@comtv.ru