This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc interprets -0 incorrectly
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Justin Pryzby <justinpryzby at users dot sourceforge dot net>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 6 Dec 2002 15:32:02 -0800
- Subject: Re: gcc interprets -0 incorrectly
- References: <20021206224313.GA17796@perseus.homeunix.net>
On Fri, Dec 06, 2002 at 05:43:13PM -0500, Justin Pryzby wrote:
> /*
> * GCC interprets -0 as -INT_MIN==-INT_MAX - 1 (See <limits.h>).
> * It knows how to overflow from positive to negative,
> * and from negative to positive.
No, both -0 and 0 are represented as 0x00000000 in 32-bit
twos-complement integer arithmetic. Your code does not calculate -0.
> int i=0;
> struct byte_struct {
> int a:1;
> int b:6;
> int c:1;
> } *byte;
>
> byte=(struct byte_struct *) (((char *) &i)+3);
> byte->c=1;
This has undefined behavior. However, assuming it does what a literal
translation to assembly language would do, its effect is to set the
high bit of a four-byte little-endian integer to 1. In other words,
it's equivalent to
int i = 0x80000000U;
That has the numeric value -2147483648, which is indeed INT_MIN in
32-bit twos-complement arithmetic. You seem to think that integer
arithmetic is sign-and-magnitude, which is not true for any
architecture supported by GCC.
Please read up on twos-complement arithmetic.
zw