INT_MIN and compiler diagnostic

[p_cricket_guy]

Please see this test program:

1 #include <stdio.h>
2 #include <stdlib.h>
3 #include <limits.h>
4
5 int main (void)
6 {
7 int y = -2147483648;
8 int x = INT_MIN;
9
10 printf("INT_MAX = %d INT_MIN = %d\n", INT_MAX,
INT_MIN);
11 printf("x = %d y = %d\n", x, y);
12
13
14 return EXIT_SUCCESS;
15 }

Output:
INT_MAX = 2147483647 INT_MIN = -2147483648
x = -2147483648 y = -2147483648

When I compile this using gcc, I get a diagnostic on line 7:

[pcg@mylinux test]$gcc -ansi -pedantic -Wall -o /tmp/x /tmp/x.c
/tmp/x.c: In function `main':
/tmp/x.c:7: warning: this decimal constant is unsigned only in ISO C90

However, on my system INT_MIN is indeed -2147483648 as
suggested by the output of above program.

Is there any specific reason for this diagnostic [as per ANSI C] ?

However, line 8, which is logically equivalent to line 7 does not
produce any diagnostic. INT_MIN is defined in limits.h as:

# define INT_MIN (-INT_MAX - 1)
# define INT_MAX 2147483647

Thanks,
pcg

[David Thompson]

On 28 Feb 2007 18:00:33 GMT, Chris Torek <no****@torek.n etwrote:
<snip usually-longish signed-vs-unsigned etc.>

(Ones' complement systems are rare these days, in part because
people are more interested in getting the wrong answer as fast as
possible than in getting the right answer. :-) )

How so? I haven't heard of any case where 1sC gives a 'right' answer
that 2sC doesn't, for integers. (For floating point, the sign of zero
sometimes matters, and TTBOMK all common formats are S&M and do
preserve it; certainly the standardized one does.)

And it was my understanding that in earlier days a main advantage of
1sC was that it was faster for negate. It was only when MSI (and
higher) made carry-lookahead effectively free (in both cost and time)
that 2sC won out.

[Chris Torek]

>On 28 Feb 2007 18:00:33 GMT, Chris Torek <no****@torek.n etwrote:

><snip usually-longish signed-vs-unsigned etc.>

>(Ones' complement systems are rare these days, in part because
people are more interested in getting the wrong answer as fast as
possible than in getting the right answer. :-) )

In article <la************ *************** *****@4ax.com>,
David Thompson <da************ @verizon.netwro te:

>How so? I haven't heard of any case where 1sC gives a 'right' answer
that 2sC doesn't, for integers.

The one usual "good case" here is when the bit pattern for -0 is
used as a trap representation, and "uninitiali zed" variables of
signed integral types are set to this bit pattern. But the remark
was meant more as a jab at the usual obsession with speed, often
to the exclusion of all else, including accuracy, hence the ":-)".
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.