In article <1100g0e$1lt8i$1@kst.eternal-september.org>,[...]
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
A naive compiler that performs no optimizations would generate>
code for foo() that attempts to compute (INT_MAX+1)*0 step by
step, without recognizing the overflow, and that code would never
be executed.
Sure. But a far more sophisticated translator (and I would
argue a nefarious one) could emulate that code, decide it was
UB, and immediately fail translation with an error.
I disagree. That's not a sensible interpretation of what the
standard says.
A call to a foo() would have undefined behavior if it occurred. There
is no call to foo().
Similarly:
int a = ..., b = ...;
int c;
if (b != 0) {
c = a / b;
}
else {
c = 0;
}
A division by zero would have undefined behavior if it occurred,
but it never occurs. A compiler cannot reject the above code
because of UB that never happens.
[...]
It returns a status of 0 from main and does nothing else.>
A conforming implementation *must* generate code that implements
that behavior.
I have yet to find or be shown a way in which the standard
actually guarantees that.
How does the standard guarantee *anything*?
This strictly conforming program:
int main(void) { return 0; }
when executed returns a status of 0 from main and does nothing else.
Adding an uncalled function to the same source file doesn't change
that.
[...]
There was, once, a view that was almost universally shared that
UB was meant for things that could not be precisely described
because hardware was too varied. We're well past that; now it's
a vehicle for compiler writers to make benchmarks faster, but is
(generally) hostile to programmers. A lot of hay is made about
it in this group, but at the core, it's just (ironically) not
well-defined.
The standard does say what UB is meant for. It says what UB
*is*, and what constructs lead to it (by omission in some cases).
Any optimization tricks played by compiler implementers must be
based on that specification.
[...]
I agree. printf("hello, world\n") must write that string to standard>
output, which may be a file or an interactive device. Just what
that means is unspecified or implementation-defined. It might be
printed in EBCDIC or incised into clay tablets. Closing stdout,
which occurs when main() terminates, might involve firing the tablet
or emitting control sequences for a screen reader.
Exactly. It could also emit the string, "GOODBYE WORLD."
No, it couldn't. It must emit "hello, world\n" in some form.
It must emit the character 'h' as represented in the execution
character set, followed by 'e', and so on.
[...]
This presupposes that the program is strictly conforming, but
in the limit, the standard can be interpreted in such a way that
if any statement in the program is proveably UB (as this one is)
then the program cannot said to be strictly conforming.
It's not UB if it's never called. Behavior that doesn't happen is
not behavior.
I did not presuppose that the program is strictly conforming.
I read the source code and determined that it meets the standard's
definition of a strictly conforming program.
[...]
Ok, so in that case, would we say that "`foo` has undefined
behavior?" The qualification, "...if called" seems superfluous,
and I don't see anything in the standard that explicitly
disagrees.
The qualification "if called" is the whole point.
[...]
UB can time-travel, however. Because it's undefined, the
compiler is free to assume that it never executes, or that it
always executes.
"UB can time-travel" is perhaps an oversimplification. An example is
a bug that occurred in the Linux kernel, something like:
void func(int *ptr) {
do_something_with(*ptr);
if (ptr != NULL) {
blah();
}
}
The compiler, on seeing the expression `*ptr`, assumed that `ptr` is
not null, and elided the test on the following line.
But even assuming that's valid, a compiler absolutely cannot assume that
an instance UB always executes when, according to the semantics of the
program, it provably never executes.
[...]
So any program that produces no output at all is strictly
conforming? Then what about this?
>
#include <limits.h>
>
int
zero(void)
{
return (INT_MAX + 1) * 0;
}
>
int
main(void)
{
(void)zero();
return 0;
}
That's an interesting point. A more terse example:
#include <limits.h>
int main(void) {
int unused = INT_MAX + 1;
}
This program produces no output, yet clearly executes a function
that contains an expression that induces undefined behavior when
evaluated. I suppose an argument could be made that it _might_
generate output due to UB, as UB imposes no requirements Not to
do so, so perhaps the _absence_ of output depends on UB.
The program clearly has undefined behavior when executed, but no
output depends on that undefined behavior. In my humble opinion,
this demonstrates a flaw in the standard's definition of "strictly
conforming program". (As a programmer: Don't do that.)
[...]
In my ideal world, C would be rigorously defined with a precise
operational semantics. That would be accompanied by an
explanatory document that presented those semantics in lay
terms in prose, similar to the standard now, for those who did
not want to drive Coq or something similar. But at least we'd
have something definitive to define the language, so that when
there was apparent ambiguity, we had some objective metric by
which to judge. The C standard, as written, is nowhere close as
precise as it should be.
I do not think that this will ever happen: not only would it be
very difficult to produce (as you noted elsethread), I think the
compiler writers would rebel if they felt that their UB hands
were tied by a formal specification.
"There are only two kinds of languages: the ones people complain
about and the ones nobody uses."
-- Bjarne Stroustrup
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
Les messages affichés proviennent d'usenet.