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

 

[bytebro]

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

On mine (Sun sparc) using gcc with exactly the same flags I get

x.c:7: warning: decimal constant is so large that it is unsigned

The program output is:

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

So amusingly, it tells me the constant is unsigned, then prints it
signed.

Where's a language lawyer when you need one?!

 

[Beej Jorgensen]

/tmp/x.c:7: warning: this decimal constant is unsigned only in ISO C90

I think it was addressed in this thread:

http://tinyurl.com/ytuxdv

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

This produces the warning:

int y = -2147483648;

whereas this does not:

int y = (-2147483647 - 1);

(Interestingly, though, I guess I expected the preprocessor to calculate
the final answer before passing it to the compiler, and it doesn't.

And now, it doesn't even make sense that the preprocessor would do it.
I mean, the compiler has to do that kind of stuff anyway, right?

So why did I have it in the back of my mind that the preprocessor
sometimes did simple math? Some holdover from the olden days of not-so-
optimal compilers?)

Finally,

int y = -0x80000000;

does not produce a warning, though it is the same as -2147483648.
Apparently the rules are different for hex constants than they are for
decimal constants (c99 6.4.4.1p5).

-Beej

 

[pete]

bytebro wrote:

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

So amusingly, it tells me the constant is unsigned, then prints it
signed.

Where's a language lawyer when you need one?!

If INT_MAX equals 2147483647,
the the type of 2147483648 can't be type int, can it?

 

[Chris Dollin]

Erm... it doesn't say "2147483648", it says "-2147483648", which is
exactly equal to INT_MIN, and is therefore a valid int value. The
warning is therefore misleading, no?

No.

`-2147483648` isn't a literal constant. It's an expression, the
negation of `2147483648`.

 

[bytebro]

If INT_MAX equals 2147483647,
the the type of 2147483648 can't be type int, can it?

Erm... it doesn't say "2147483648", it says "-2147483648", which is
exactly equal to INT_MIN, and is therefore a valid int value. The
warning is therefore misleading, no?

 

[Dik T. Winter]

>
> Erm... it doesn't say "2147483648", it says "-2147483648", which is
> exactly equal to INT_MIN, and is therefore a valid int value. The
> warning is therefore misleading, no?

Does it tell you "-2147483648" is unsigned? Strange. It should
tell you the constant is unsigned, and the constant is "2147483648".
There are no negative constants in C.

 

[CBFalconer]

.... snip ...

This produces the warning:

int y = -2147483648;

whereas this does not:

int y = (-2147483647 - 1);
.... snip ...

Finally,

int y = -0x80000000;

does not produce a warning, though it is the same as -2147483648.
Apparently the rules are different for hex constants than they are
for decimal constants (c99 6.4.4.1p5).

In the first case you are negating the int 2147483648, which has
already overflowed and caused un/implementation defined behaviour.
In the second, you are negating the unsigned int 0x80000000, which
follows the rules for unsigned ints, and does not overflow.

 

[Richard Heathfield]

Dik T. Winter said:

There are no negative constants in C.

"No" is a counter-example.

 

[bytebro]

No.

`-2147483648` isn't a literal constant. It's an expression, the
negation of `2147483648`.

Wow. I've been mucking around with C for about 20 years now, and
that's the first time I've come across that!

The thing is, in the OP's code lines 7 and 8, it says:

7 int y = -2147483648;
8 int x = INT_MIN;

which are _completely_ equivalent (INT_MIN is _defined_ as
-2147483648), and yet line 7 generates the warning:

/tmp/x.c:7: warning: this decimal constant is unsigned only in ISO
C90

on his system, and the warning:

x.c:7: warning: decimal constant is so large that it is unsigned

on my system, but line 8 generates no warning at all for either of us.

 

[Nelu]

Dik T. Winter said:



"No" is a counter-example.

It's a string literal. Attempting to modify it may succeed (UB).
It will compile fine so it's not a good example, right?

 

[Dik T. Winter]

....
> The thing is, in the OP's code lines 7 and 8, it says:
>
> 7 int y = -2147483648;
> 8 int x = INT_MIN;
>
> which are _completely_ equivalent (INT_MIN is _defined_ as
> -2147483648), and yet line 7 generates the warning:

Please check it. It will probably defined as (- 2147483647 - 1),
which is something different.

 

[Richard Tobin]

The thing is, in the OP's code lines 7 and 8, it says:

7 int y = -2147483648;
8 int x = INT_MIN;

which are _completely_ equivalent (INT_MIN is _defined_ as
-2147483648)

According to the OP, on his system INT_MIN is defined as

# define INT_MIN (-INT_MAX - 1)

which produces the same result, but does not involve the literal 2147483648.
This seems to be a common trick; on my Mac it is defined as (-0x7fffffff - 1).

-- Richard

 

[strangerdream]

There are no negative constants in C.

But the warning message says:
warning: this decimal constant is unsigned only in ISO C90

What is a signed constant then?

 

[Richard Tobin]

There are no negative constants in C.

But the warning message says:
warning: this decimal constant is unsigned only in ISO C90

What is a signed constant then?[/QUOTE]

The question is whether the constant has an unsigned type, or is
a positive value of a signed type.

-- Richard

 

[Chris Torek]

Given:

int y = - ( 2147483648 );

to which I have added parentheses and whitespace for clarity:

On mine (Sun sparc) using gcc with exactly the same flags I get
x.c:7: warning: decimal constant is so large that it is unsigned

The constant is, indeed, unsigned (in C89/C90) on that implementation,
as others have noted. (In C99, on that implementation, the constant
has type "long long".)

The reason for this is clearer in the version with parentheses:
the constant in question is 2147483648, *not* -2147483648. The
unary "-" operator is, in C, applied later. Since 2147483648 has
type "unsigned int", the unary minus computes the "mathematical
result" of UINT_MAX + 1 - 2147483648. Given that UINT_MAX is (on
that implementation) 4294967295, the result is 2147483648. Thus,
the assignment:

int y = - ( 2147483648 );

attempts to put 2147483648U into an "int", with compiler- and/or
hardware-dependent results.

The program output [includes] y = -2147483648

So amusingly, it tells me the constant is unsigned, then prints it
signed.

Where's a language lawyer when you need one?!

The output comes from a printf() that prints y, using the "%d"
format. The %d format tells printf() to expect an "int" -- i.e.,
a signed integer -- and y is indeed an "int". The actual value
stored in y, when this overly-large "unsigned int" constant is
stored there, depends on the implementation, but in this case, the
stored value is in fact -2147483648, because 2147483648U has bit
pattern 0x80000000 and -2147483648 also has bit pattern 0x80000000:
this particular implementation has 32-bit two's complement
representation.

If this were a ones' complement system, 0x80000000 would represent
-2147483647 instead. In that case, the fragment:

int y = 2147483648U;
printf("y = %d\n", y);

would most likely print:

y = -2147483647;

although this would depend on additional details about the
implementation.

(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. )

 

[Clark Cox]

But the warning message says:
warning: this decimal constant is unsigned only in ISO C90

What is a signed constant then?

It is a constant with a signed type (i.e. int or long). Just because
something is signed doesn't mean that it is negative. Under C90, a
constant to large to fit in a long would have the type (unsigned long).
Under C99, this is different (because of the addition of long long and
the associated changes to the promotion rules)

 

[Keith Thompson]

(Interestingly, though, I guess I expected the preprocessor to calculate
the final answer before passing it to the compiler, and it doesn't.

And now, it doesn't even make sense that the preprocessor would do it.
I mean, the compiler has to do that kind of stuff anyway, right?

So why did I have it in the back of my mind that the preprocessor
sometimes did simple math? Some holdover from the olden days of not-so-
optimal compilers?)

[...]

The preprocessor does do simple math within preprocessor directives.
For example:

#if 2 + 2 == 4

is evaluated by the preprocessor.

Arithmetic expressions outside preprocessor directives may be (and in
some cases, must be) evaluated at compilation time, but not during the
preprocessing phases.

 

[Beej Jorgensen]

The preprocessor does do simple math within preprocessor directives.

Ah, that makes sense. Thanks!

-Beej

 

[Old Wolf]

In the first case you are negating the int 2147483648, which has
already overflowed and caused un/implementation defined behaviour.

Integer constants do not overflow or cause un/impl. defined behaviour.
(Except, of course, for the fact that it is implementation-defined
whether this value exceeds INT_MAX or not).

In C90 the above two lines are exactly equivalent.

Supposing INT_MAX and LONG_MAX to be 2147483647, then the constant
2147483648 has type 'unsigned int' in C90, or 'long long' in C99.
However, 0x80000000 has type 'unsigned int' in both dialects.

I presume the warning message is because the compiler writer thought
it unintuitive that the decimal constant could have an unsigned type.
The warning occurs even if the constant occurs without being negated
or assigned.

In the second, you are negating the unsigned int 0x80000000, which
follows the rules for unsigned ints, and does not overflow.

Negating a positive value never overflows, signed or not.

Anyway, in C90, 2147483648 is also an unsigned int so it has the same
negation as 0x80000000, ie. (UINT_MAX + 1 - 0x80000000),
mathematically.
(Curiously, this number is its own negative in this case).

Implementation-defined behaviour is not caused until this value is
used to initialize an int.

In C99 the behaviour is well-defined because the negative long long
value is within the range of signed int.