From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45496 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OlSnB-0006su-2o for qemu-devel@nongnu.org; Tue, 17 Aug 2010 16:29:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OlSn9-0002Ww-RI for qemu-devel@nongnu.org; Tue, 17 Aug 2010 16:29:52 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:57443) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OlSn9-0002Wo-MX for qemu-devel@nongnu.org; Tue, 17 Aug 2010 16:29:51 -0400 Received: by gwb11 with SMTP id 11so2945290gwb.4 for ; Tue, 17 Aug 2010 13:29:50 -0700 (PDT) Message-ID: <4C6AF139.3040507@codemonkey.ws> Date: Tue, 17 Aug 2010 15:29:45 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/5] CODING_STYLE: add C type rules References: <4C6A43B5.40809@redhat.com> <4C6AE1AA.7000200@redhat.com> <4C6AE665.7090502@redhat.com> In-Reply-To: <4C6AE665.7090502@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 08/17/2010 02:43 PM, 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. > FWIW, that type is intptr_t and it was introduced in C99. Regards, Anthony Liguori > Depending on your viewpoint it is either it not being a standard that is > bad, or the LLP64 that is bad. > > Anyway this is personal preference. > > Jes > > >