From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=49083 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OlS4m-0002Dw-Ju
	for qemu-devel@nongnu.org; Tue, 17 Aug 2010 15:44:02 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <Jes.Sorensen@redhat.com>) id 1OlS4V-0004d1-87
	for qemu-devel@nongnu.org; Tue, 17 Aug 2010 15:43:44 -0400
Received: from mx1.redhat.com ([209.132.183.28]:20861)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <Jes.Sorensen@redhat.com>) id 1OlS4U-0004cv-TI
	for qemu-devel@nongnu.org; Tue, 17 Aug 2010 15:43:43 -0400
Message-ID: <4C6AE665.7090502@redhat.com>
Date: Tue, 17 Aug 2010 21:43:33 +0200
From: Jes Sorensen <Jes.Sorensen@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 2/5] CODING_STYLE: add C type rules
References: <AANLkTinM4GFK8cUj3gAyUNFT_9yM83MGTbDiwLjvCJi2@mail.gmail.com>
	<4C6A43B5.40809@redhat.com>
	<AANLkTin1dOOJAhkNLcGKXBbXFwRLfi=U0z30aTs4596z@mail.gmail.com>
	<alpine.LNX.2.00.1008172249450.1411@linmac>
	<4C6AE1AA.7000200@redhat.com>
	<alpine.LNX.2.00.1008172324090.1756@linmac>
In-Reply-To: <alpine.LNX.2.00.1008172324090.1756@linmac>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: malc <av1474@comtv.ru>
Cc: Blue Swirl <blauwirbel@gmail.com>, qemu-devel <qemu-devel@nongnu.org>

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.

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