From owner-freebsd-hackers@FreeBSD.ORG  Thu May  1 15:31:48 2003
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id D3E0237B401; Thu,  1 May 2003 15:31:48 -0700 (PDT)
Received: from bitblocks.com (bitblocks.com [209.204.185.216])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 4498E43FBD; Thu,  1 May 2003 15:31:48 -0700 (PDT)
	(envelope-from bakul@bitblocks.com)
Received: from bitblocks.com (localhost [127.0.0.1])
	by bitblocks.com (8.12.9/8.12.9) with ESMTP id h41MVePF062201;
	Thu, 1 May 2003 15:31:40 -0700 (PDT)
	(envelope-from bakul@bitblocks.com)
Message-Id: <200305012231.h41MVePF062201@bitblocks.com>
To: Stefan Farfeleder <stefan@fafoe.dyndns.org>
In-reply-to: Your message of "Fri, 02 May 2003 00:16:32 +0200."
             <20030501221631.GB546@wombat.fafoe> 
Date: Thu, 01 May 2003 15:31:40 -0700
From: Bakul Shah <bakul@bitblocks.com>
cc: Mike Hunter <mhunter@ack.Berkeley.EDU>
cc: Dag-Erling Smorgrav <des@ofug.org>
cc: hackers@freebsd.org
Subject: Re: incorrect enum warning? 
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 01 May 2003 22:31:49 -0000

> > int main ()
> > {
> >         printf("%d\n", (0x80000000 == INT_MIN));
> >         return 0;
> > }
> > 
> > ./a.out
> > 1
> > 
> > Just pointing out that they do "==" each other, which is what was said.
> 
> That is because the comparison is done in unsigned arithmetics due to
> the "usual arithmetic conversions".  The negative int value INT_MIN is
> converted to unsigned int by adding UINT_MAX + 1 before the comparison
> is evaluated.

\begin{nitpicking}
0x80000000 is *not* an unsigned int, just a regular signed
int but outside the legal range.  An unsigned int literal has
to have a U at the end.  Since 0x80000000 > INT_MAX, all bets
are off.  The result is unspecified and happens to be 1 on a
2s complement 32 bit machine but can be 0 or anything else on
a ones complement machine or where int is not 32 bits wide.
\end{nitpicking}