From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MjkYJ-00080u-3c
	for qemu-devel@nongnu.org; Fri, 04 Sep 2009 21:58:55 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MjkYE-00080h-5o
	for qemu-devel@nongnu.org; Fri, 04 Sep 2009 21:58:54 -0400
Received: from [199.232.76.173] (port=40354 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MjkYE-00080e-2c
	for qemu-devel@nongnu.org; Fri, 04 Sep 2009 21:58:50 -0400
Received: from mail2.shareable.org ([80.68.89.115]:40049)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <jamie@shareable.org>) id 1MjkYD-0005Fz-GW
	for qemu-devel@nongnu.org; Fri, 04 Sep 2009 21:58:49 -0400
Date: Sat, 5 Sep 2009 02:58:42 +0100
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] [PATCH v2] Fix compilation of check-qint.c by using
	a long long integer constant
Message-ID: <20090905015842.GB24516@shareable.org>
References: <1252084198-15375-1-git-send-email-Pierre.Riteau@irisa.fr>
	<20090904172935.GA4163@1und1.de>
	<Pine.LNX.4.64.0909042149080.2268@linmac.oyster.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.64.0909042149080.2268@linmac.oyster.ru>
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: malc <av1474@comtv.ru>
Cc: qemu-devel@nongnu.org, Reimar =?iso-8859-1?Q?D=F6ffinger?= <Reimar.Doeffinger@gmx.de>, Pierre Riteau <Pierre.Riteau@irisa.fr>

malc wrote:
> > > -    const int64_t value = 0xffffffffffffffff;
> > > +    const int64_t value = 0xffffffffffffffffLL;
> > 
> > Hm, well it does not really fit in a signed long long either (so from that
> > aspect it should be ULL).
> > Should it not be simply -1 (does qemu assume all architectures
> > use two's complement?)?
> 
> Yes.

Yes, but be aware that GCC nowadays does some optimisations which
assume calculations do not wraparound when using signed types.  See
-fwrapv and -fno-strict-overflow.  They tripped up the Linux kernel
recently, causing some range tests to be optimised away.  Those
optimisations warrant caution when thinking in two's complement while
using signed types.

For unsigned types, the ANSI C language uses arithmetic (mod 2^bits)
for unsigned types.  You can always write 0ULL-1, even theoretically
on non-two's complement machines: that's well-defined in C to have all
one bits set.

-- Jamie