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

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Richard Heathfield wrote:

Keith Thompson said:

<snip>

For example this program:

#include <stdio.h>
int main(void)
{
printf("'a' = %d\n", 'a');
return 0;
}

is not strictly conforming because its output depends on
implementation-defined behavior, but a conforming hosted
implementation must accept it.

Why?

4p3: "A program that is correct in all other aspects, operating on
correct data, containing unspeci�ed behavior shall be a correct
program and act in accordance with 5.1.2.3."

And implementation-defined behaviour is a special case of unspecified
behaviour.

[Keith Thompson]

Richard Heathfield <rj*@see.sig.in validwrites:

Keith Thompson said:
<snip>

>For example this program:

#include <stdio.h>
int main(void)
{
printf("'a' = %d\n", 'a');
return 0;
}

is not strictly conforming because its output depends on
implementati on-defined behavior, but a conforming hosted
implementati on must accept it.

Why?

Because.

A more specific question will yield a more specific answer. 8-)}

Seriously, are you suggesting that a conforming hosted implementation
is allowed to reject the above, but is not allowed to reject a similar
strictly conforming program such as the following?

#include <stdio.h>
int main(void)
{
printf("'a' = %d\n", 97);
return 0;
}

(The output is factually incorrect on non-ASCII systems, but of course
that's irrelevant to strict conformance.)

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Clark Cox said:

On 2007-03-01 08:47:26 -0800, Richard Heathfield <rj*@see.sig.in valid>
said:

>Keith Thompson said:

<snip>

>>For example this program:

#include <stdio.h>
int main(void)
{
printf("'a' = %d\n", 'a');
return 0;
}

is not strictly conforming because its output depends on
implementatio n-defined behavior, but a conforming hosted
implementatio n must accept it.

Why?

Why wouldn't it have to accept it?

The Standard says:

"A conforming hosted implementation shall accept any strictly conforming
program."

On that basis, I consider it a requirement upon conforming hosted
implementations that they shall accept any strictly conforming program.
I can see no such requirement being imposed on conforming hosted
implementations with regard to programs that are not strictly
conforming. Can you?

>
'a' is a prefectly valid integer value, suitable for passing to printf
through the %d specifier. The program will produce different output
depending on the exact value of 'a', but I cannot imagine any reason
that a compiler could reject it outright

I can, but then I have a pretty good imagination. Can you *prove* that a
compiler *must not* reject it outright, with reference to the Standard?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Heathfield]

Harald van D?k said:

Richard Heathfield wrote:

>Keith Thompson said:

<snip>

For example this program:

#include <stdio.h>
int main(void)
{
printf("'a' = %d\n", 'a');
return 0;
}

is not strictly conforming because its output depends on
implementation-defined behavior, but a conforming hosted
implementation must accept it.

Why?

4p3: "A program that is correct in all other aspects, operating on
correct data, containing unspeci[fi]ed behavior shall be a correct
program and act in accordance with 5.1.2.3."

And implementation-defined behaviour is a special case of unspecified
behaviour.

Where does the Standard require conforming hosted (or indeed
freestanding!) implementations to accept correct programs that are not
strictly conforming?
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Heathfield]

Keith Thompson said:

<snip>

Seriously, are you suggesting that a conforming hosted implementation
is allowed to reject the above, but is not allowed to reject a similar
strictly conforming program such as the following?

#include <stdio.h>
int main(void)
{
printf("'a' = %d\n", 97);
return 0;
}

No, I'm suggesting that I can't find any requirement on a conforming
implementation (of whatever flavour - either hosted or freestanding) to
accept programs that are not strictly conforming. Perhaps such a
requirement exists and I simply haven't discovered it yet. Can you
enlighten me as to where in the Standard this requirement is
documented?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Richard Heathfield wrote:

Harald van D?k said:

Richard Heathfield wrote:

Keith Thompson said:

<snip>

For example this program:

#include <stdio.h>
int main(void)
{
printf("'a' = %d\n", 'a');
return 0;
}

is not strictly conforming because its output depends on
implementation-defined behavior, but a conforming hosted
implementation must accept it.

Why?

4p3: "A program that is correct in all other aspects, operating on
correct data, containing unspeci[fi]ed behavior shall be a correct
program and act in accordance with 5.1.2.3."

And implementation-defined behaviour is a special case of unspecified
behaviour.

Where does the Standard require conforming hosted (or indeed
freestanding!) implementations to accept correct programs that are not
strictly conforming?

In the paragraph I quoted. If the implementation doesn't accept the
correct program, it cannot act in accordance with 5.1.2.3.

See also 4p1. "In this International Standard, "shall" is to be
interpreted as a requirement on an implementation or on a program;
[...]" 4p3 contains a "shall", cannot be a requirement on a program,
so is a requirement on an implementation.

[Richard Heathfield]

Harald van D?k said:

Richard Heathfield wrote:

<snip>

>Where does the Standard require conforming hosted (or indeed
freestanding !) implementations to accept correct programs that are
not strictly conforming?

In the paragraph I quoted. If the implementation doesn't accept the
correct program, it cannot act in accordance with 5.1.2.3.

You have the makings of a point, but I am not yet convinced. Can you
make your reasoning clearer, please?

See also 4p1. "In this International Standard, "shall" is to be
interpreted as a requirement on an implementation or on a program;
[...]" 4p3 contains a "shall", cannot be a requirement on a program,
so is a requirement on an implementation.

This assumes that implementations are required to accept correct
programs, and I have yet to see any unequivocal evidence of this
requirement. I hope you're right, but I can't yet see *why* you're
right.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Keith Thompson]

Richard Heathfield <rj*@see.sig.in validwrites:

Harald van D?k said:

>Richard Heathfield wrote:

<snip>

>>Where does the Standard require conforming hosted (or indeed
freestanding! ) implementations to accept correct programs that are
not strictly conforming?

In the paragraph I quoted. If the implementation doesn't accept the
correct program, it cannot act in accordance with 5.1.2.3.

You have the makings of a point, but I am not yet convinced. Can you
make your reasoning clearer, please?

>See also 4p1. "In this International Standard, "shall" is to be
interpreted as a requirement on an implementation or on a program;
[...]" 4p3 contains a "shall", cannot be a requirement on a program,
so is a requirement on an implementation.

This assumes that implementations are required to accept correct
programs, and I have yet to see any unequivocal evidence of this
requirement. I hope you're right, but I can't yet see *why* you're
right.

I assume there's something unclear here, but I'm not clear on what it
is.

C99 4p3:

A program that is correct in all other aspects, operating on
correct data, containing unspecified behavior shall be a correct
program and act in accordance with 5.1.2.3.

(5.1.2.3 is "Program execution".)

If the implementation rejects a "correct program", that program cannot
act in accordance with 5.1.2.3. A "correct program" must act in
accordance with 5.1.2.3. Therefore, a conforming implementation must
not reject a "correct program".

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Keith Thompson said:

<snip>

If the implementation rejects a "correct program", that program cannot
act in accordance with 5.1.2.3. A "correct program" must act in
accordance with 5.1.2.3. Therefore, a conforming implementation must
not reject a "correct program".

I'm inclined to agree, but I would not like to have to defend such a
position myself.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Eric Sosman]

Dik T. Winter wrote:

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

Nit-picking, angels-on-pinhead-counting, pedant-delighting
counter-example:

enum { MINUS = -1, ZERO, PLUS };

Now `MINUS' is a constant with a negative value.

--
Eric Sosman
es*****@acm-dot-org.invalid