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]

On 28 Feb, 10:07, [e-mail] wrote:

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]

<p_***********@yahoo.co.inwrote:

>/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?

--
pete

[bytebro]

On 28 Feb, 12:34, pete <[e-mail]:

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?

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?

[Chris Dollin]

bytebro wrote:

On 28 Feb, 12:34, pete <[e-mail]:

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

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

--
Chris "electric hedgehog" Dollin
"People are part of the design. It's dangerous to forget that." /Star Cops/

[Dik T. Winter]

In article <11**********************@8g2000cwh.googlegroups.c om"bytebro" <ke**********@aah.co.ukwrites:

On 28 Feb, 12:34, pete <[e-mail]:

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?

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.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Richard Heathfield]

Dik T. Winter said:

<snip>

There are no negative constants in C.

"No" is a counter-example.

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

[CBFalconer]

Beej Jorgensen wrote:

>

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

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[bytebro]

On 28 Feb, 13:20, Chris Dollin <[e-mail]:

bytebro wrote:

On 28 Feb, 12:34, pete <[e-mail]:

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?

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]

Richard Heathfield wrote:

Dik T. Winter said:

<snip>

>There are no negative constants in C.

"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? :-)

--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)

[Dik T. Winter]

In article <11**********************@s48g2000cws.googlegroups .com"bytebro" <ke**********@aah.co.ukwrites:

On 28 Feb, 13:20, Chris Dollin <[e-mail]:

....

No.

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

....

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.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Richard Tobin]

In article <11**********************@s48g2000cws.googlegroups .com>,
bytebro <ke**********@aah.co.ukwrote:

>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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[strangerdream]

On Feb 28, 7:14 pm, "Dik T. Winter" <[e-mail]:
<snip>

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]

In article <11**********************@z35g2000cwz.googlegroups .com>,
<st***********@gmail.comwrote:

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

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

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Chris Torek]

Given:

int y = - ( 2147483648 );

to which I have added parentheses and whitespace for clarity:

In article <11**********************@h3g2000cwc.googlegroups. com>
bytebro <ke**********@aah.co.ukwrote:

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

[Clark Cox]

On 2007-02-28 09:01:31 -0800, st***********@gmail.com said:

On Feb 28, 7:14 pm, "Dik T. Winter" <[e-mail]:
<snip>

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

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]

Beej Jorgensen <be**@beej.uswrites:
[...]

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

--
Keith Thompson (The_Other_Keith) 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"

[Beej Jorgensen]

Keith Thompson <ks***@mib.orgwrote:

>The preprocessor does do simple math within preprocessor directives.

Ah, that makes sense. Thanks!

-Beej

[Old Wolf]

On Mar 1, 3:42 am, CBFalconer <[e-mail]:

Beej Jorgensen wrote:

This produces the warning:
int y = -2147483648;
Finally,
int y = -0x80000000;
does not produce a warning

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.

[Keith Thompson]

"Old Wolf" <ol*****@inspire.net.nzwrites:
[...]

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

[...]

I don't think that's quite true. Consider an integer const whose
value cannot be represented in any integer type.

For example, assume that long long is 64 bits and there are no extended
integer types. Then the integer constant 99999999999999999999 (that's
20 9's; the value exceeds 2**66) *sort of* violates the constraint
in C99 6.4.4p1:

The value of a constant shall be in the range of representable
values for its type.

except that the C99 6.4.4.1 doesn't say what its type is:

The type of an integer constant is the first of the corresponding
list in which its value can be represented.
[...]
[No suffix, decimal constant]
int
long int
long long int
[...]
If an integer constant cannot be represented by any type in its
list, it may have an extended integer type, if the extended
integer type can represent its value. If all of the types in the
list for the constant are signed, the extended integer type shall
be signed. If all of the types in the list for the constant are
unsigned, the extended integer type shall be unsigned. If the list
contains both signed and unsigned types, the extended integer type
may be signed or unsigned.

If there are no extended integer types, that last paragraph doesn't
apply.

It *should* be a constraint violation, but it may be just undefined
behavior.

--
Keith Thompson (The_Other_Keith) 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"

[Dave Vandervies]

In article <54*************@mid.individual.net>,
Nelu <sp*******@gmail.comwrote:

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

I don't believe a compiler is required to accept code that invokes
undefined behavior.

For the language lawyers: Is a sufficiently clever compiler allowed to
refuse to compile this code?
--------
#include <stdio.h>

int main(void)
{
char *msg="Hello, World!";
msg[5]=0;
printf("%s\n",msg);
return 0;
}
--------
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca

If people behave like children they should be spanked. Unless they enjoy it.
--DG in uw.general

[Nelu]

Dave Vandervies wrote:

In article <54*************@mid.individual.net>,
Nelu <sp*******@gmail.comwrote:

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

I don't believe a compiler is required to accept code that invokes
undefined behavior.

For the language lawyers: Is a sufficiently clever compiler allowed to
refuse to compile this code?
--------
#include <stdio.h>

int main(void)
{
char *msg="Hello, World!";
msg[5]=0;
printf("%s\n",msg);
return 0;
}
--------

It will compile fine in some particular cases. In general a
compiler may "terminate a translation or execution (with the
issuance of a diagnostic message).".

--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)

[Keith Thompson]

dj******@caffeine.csclub.uwaterloo.ca (Dave Vandervies) writes:

In article <54*************@mid.individual.net>,
Nelu <sp*******@gmail.comwrote:

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

I don't believe a compiler is required to accept code that invokes
undefined behavior.

For the language lawyers: Is a sufficiently clever compiler allowed to
refuse to compile this code?
--------
#include <stdio.h>

int main(void)
{
char *msg="Hello, World!";
msg[5]=0;
printf("%s\n",msg);
return 0;
}
--------

Yes. C99 3.4.3p2:

NOTE Possible undefined behavior ranges from ignoring the
situation completely with unpredictable results, to behaving
during translation or program execution in a documented manner
characteristic of the environment (with or without the issuance of
a diagnostic message), to terminating a translation or execution
(with the issuance of a diagnostic message).

But I don't believe it can reject the program unless it can prove that
the statement that invokes UB is always going to be invoked.

--
Keith Thompson (The_Other_Keith) 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"

[Flash Gordon]

Dave Vandervies wrote, On 01/03/07 03:54:

In article <54*************@mid.individual.net>,
Nelu <sp*******@gmail.comwrote:

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

I don't believe a compiler is required to accept code that invokes
undefined behavior.

For the language lawyers: Is a sufficiently clever compiler allowed to
refuse to compile this code?
--------
#include <stdio.h>

int main(void)
{
char *msg="Hello, World!";
msg[5]=0;
printf("%s\n",msg);
return 0;
}

Yes, the standard explicitly allows the compiler to reject it. From
n1124.pdf, which you can find linked from
http://clc-wiki.net/wiki/c_standard we have:
| 3.4.3
|1 undefined behavior
| behavior, upon use of a nonportable or erroneous program construct or
| of erroneous data, for which this International Standard imposes no
| requirements
|2 NOTE Possible undefined behavior ranges from ignoring the situation
| completely with unpredictable results, to behaving during translation
| or program execution in a documented manner characteristic of the
| environment (with or without the issuance of a diagnostic message),
| to terminating a translation or execution (with the issuance of a
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| diagnostic message).
|3 EXAMPLE An example of undefined behavior is the behavior on
| integer overflow.

--
Flash Gordon

[Richard Heathfield]

Dave Vandervies said:

In article <54*************@mid.individual.net>,
Nelu <sp*******@gmail.comwrote:

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

I don't believe a compiler is required to accept code that invokes
undefined behavior.

For the language lawyers: Is a sufficiently clever compiler allowed
to refuse to compile this code?
--------
#include <stdio.h>

int main(void)
{
char *msg="Hello, World!";
msg[5]=0;

Yes, a conforming implementation need not accept any program that is 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.

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:

Dave Vandervies said:

>In article <54*************@mid.individual.net>,
Nelu <sp*******@gmail.comwrote:

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

I don't believe a compiler is required to accept code that invokes
undefined behavior.

For the language lawyers: Is a sufficiently clever compiler allowed
to refuse to compile this code?
--------
#include <stdio.h>

int main(void)
{
char *msg="Hello, World!";
msg[5]=0;

Yes, a conforming implementation need not accept any program that is not
strictly conforming.

I don't think that's true. A conforming implementation must accept
any program that *is* strictly conforming, but that doesn't imply that
strictly conforming programs are the only programs that must be
accepted by all conforming implementations.

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.

--
Keith Thompson (The_Other_Keith) 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>

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?

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

[Clark Cox]

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

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?

Why wouldn't it have to accept it?

'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 any more than it could reject:

#include <stdio.h>
int main(void)
{
printf("%x\n", (unsigned)-1);
return 0;
}

--
Clark S. Cox III
cl*******@gmail.com

[=?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?

4.3: "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.

[=?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.invalidwrites:

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?

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_Keith) 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.invalid>
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
implementation-defined behavior, but a conforming hosted
implementation 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.invalidwrites:

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_Keith) 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

[David Thompson]

On 28 Feb 2007 18:00:33 GMT, Chris Torek <no****@torek.netwrote:
<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.netwrote:

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

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