From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1I3Ujj-0005xl-QD
	for qemu-devel@nongnu.org; Wed, 27 Jun 2007 06:26:59 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1I3Ujh-0005xZ-Dt
	for qemu-devel@nongnu.org; Wed, 27 Jun 2007 06:26:58 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1I3Ujh-0005xW-80
	for qemu-devel@nongnu.org; Wed, 27 Jun 2007 06:26:57 -0400
Received: from wr-out-0506.google.com ([64.233.184.230])
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <blauwirbel@gmail.com>) id 1I3Ujg-0006ry-RX
	for qemu-devel@nongnu.org; Wed, 27 Jun 2007 06:26:57 -0400
Received: by wr-out-0506.google.com with SMTP id 71so128834wri
	for <qemu-devel@nongnu.org>; Wed, 27 Jun 2007 03:26:55 -0700 (PDT)
Message-ID: <f43fc5580706270326l4005852ax2a5e0cbbedddedac@mail.gmail.com>
Date: Wed, 27 Jun 2007 13:26:54 +0300
From: "Blue Swirl" <blauwirbel@gmail.com>
Subject: Re: [Qemu-devel] [PATCH, RFC] More than 2G of memory on 64-bit hosts
In-Reply-To: <200706261454.16852.paul@codesourcery.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <f43fc5580706251316q7f261d5u837b05ee0596ef68@mail.gmail.com>
	<f43fc5580706251352p18b10d13ifac7b7b1fb9d52b6@mail.gmail.com>
	<cd8ecdef0706251903v6b15eb44r6045452fe271bd13@mail.gmail.com>
	<200706261454.16852.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
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.gnu.org/pipermail/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: qemu-devel@nongnu.org

On 6/26/07, Paul Brook <paul@codesourcery.com> wrote:
> The story behind this is that ISO C89 requires that "long" be at least as big
> as a pointer (ie. "void *"). The actual requirement is that it be possible to
> store a pointer in a standard integer type, and "long" is the largest
> standard integer type.
>
> Unfortunately C99 relaxed this requirement, and allowed abominations like the
> win64 ABI.
>
> This means you have a choice: Write standard conforming code (long) that works
> on all known systems except win64, or use features that do't exist on many
> systems. IIRC C99 types like intptr_t are not supported on several fairly
> common unix systems.

In that case I'll vote for unsigned long. I'd pass the issue to those
doing a win64 port, if ever that happens.