Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!mel.dit.csiro.au!its.csiro.au!dmssyd.syd.dms.CSIRO.AU!metro!ipso!runxtsa!bde
From: bde@runx.oz.au (Bruce Evans)
Subject: Re: gcc 2.3.3 bug?
Message-ID: <1993Mar30.092201.1099@runx.oz.au>
Organization: RUNX Un*x Timeshare. Sydney, Australia.
References: <1p7c3mINNdh5@urmel.informatik.rwth-aachen.de>
Date: Tue, 30 Mar 93 09:22:01 GMT
Lines: 29
In article <1p7c3mINNdh5@urmel.informatik.rwth-aachen.de> kuku@acds.physik.rwth-aachen.de writes:
>
>Sure, I believe this is not a bug. Instead it might have creeped in
>by the various patches I applied to gcc in the context of float.h and libm.
>...
>#include <limits.h>
>
>int i = -2147483648;
>
>main() {
>
> printf("%d %d\n",INT_MIN,i);
>}
>
>My gcc2.3.3 issues a warning: integer constant so large that it is unsigned.
>Obviously it is in the range of INT_MIN and INT_MAX.
The warning is correct. The constant in the initialization of `i' is
unsigned and 1 larger than INT_MAX. It would be the same without the
`-' sign. When it is assigned to `i', overflow occurs and the result is
undefined. On 2's complement 32-bit machines like the i386, the result
is usually what you want.
INT_MIN is carefully defined as (-0x7fffffff-1) in <limits.h> so that it
is not unsigned and so that the negation doesn't cause overflow. It
should be equally carefully defined in the gcc <limits.h> as something
like (-INT_MAX-1).
--
Bruce Evans bde@runx.oz.au