INT_MIN and compiler diagnostic

[Keith Thompson]

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.

 

[Dave Vandervies]

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;
}

 

[Nelu]

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

 

[Flash Gordon]

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

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.

 

[Keith Thompson]

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.

 

[Richard Heathfield]

Dave Vandervies said:

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.

 

[Keith Thompson]

Dave Vandervies said:

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.

 

[Richard Heathfield]

Keith Thompson said:

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?

 

[Clark Cox]

Keith Thompson said:



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;
}

 

[Guest]

Keith Thompson said:



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.

 

[Guest]

Keith Thompson said:



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]

Keith Thompson said:


Why?

Because.

A more specific question will yield a more specific answer. }

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

 

[Richard Heathfield]

Clark Cox said:

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]

Harald van D?k said:

Keith Thompson said:



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?

 

[Guest]

Harald van D?k 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?

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]

Keith Thompson said:

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]

Harald van D?k said:

Richard Heathfield wrote:


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.

 

[Keith Thompson]

Harald van D?k said:

Richard Heathfield wrote:


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

 

[Richard Heathfield]

Keith Thompson said:

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.

 

[Eric Sosman]

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.