From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1IXCez-0003qD-4a
	for qemu-devel@nongnu.org; Mon, 17 Sep 2007 05:12:53 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1IXCey-0003pz-Ih
	for qemu-devel@nongnu.org; Mon, 17 Sep 2007 05:12:52 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1IXCey-0003pw-6L
	for qemu-devel@nongnu.org; Mon, 17 Sep 2007 05:12:52 -0400
Received: from kurt.tools.de ([192.76.135.70])
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <jk@tools.de>) id 1IXCex-00056T-SX
	for qemu-devel@nongnu.org; Mon, 17 Sep 2007 05:12:52 -0400
Received: from imap.tools.intra (imap.tools.intra [172.20.0.17])
	by kurt.TooLs.DE (Postfix) with ESMTP id 3EAAA45813
	for <qemu-devel@nongnu.org>; Mon, 17 Sep 2007 11:12:48 +0200 (MEST)
Received: from tiger2.tools.intra (tiger2.tools.intra [172.20.0.11])
	by imap.tools.intra (8.13.6+Sun/8.13.6) with SMTP id l8H9Ckr4026406
	for <qemu-devel@nongnu.org>; Mon, 17 Sep 2007 11:12:46 +0200 (CEST)
Message-Id: <200709170912.l8H9Ckr4026406@imap.tools.intra>
Date: Mon, 17 Sep 2007 11:12:45 +0200 (CEST)
From: Juergen Keil <jk@tools.de>
Subject: Re: [Qemu-devel] Comment for Solaris fix for the HPTC
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: HzxtHbeuq458y2efR+oKZg==
Reply-To: Juergen Keil <jk@tools.de>, 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


Andreas Schwab wrote:

> Your reference to ULONG_MAX is a red herring.  ULONG_MAX is the limit
> for unsigned long, and ULONG_LONG_MAX is the limit for unsigned long
> long.  If your compiler does not support the long long type then
> ULONG_LONG_MAX should not be defined either.  Instead, vl.c should use
> UINT64_MAX.

Looking at a (draft) c99 standard document, I don't find any references
for an ULONG_LONG_MAX macro, anyway.  The c99 <limits.h> header is supposed 
to define LLONG_MIN, LLONG_MAX and ULLONG_MAX for the "long long" and
"unsigned long long" type limits...