Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:In article <86ik81cfk5.fsf_-_@linuxsc.com>,>
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:On 2026-06-01 00:54, Keith Thompson wrote:>>[...]>
Yes, a compiler can reduce (a + b) * 0 to just 0. But it's not
required to do so, and (INT_MAX + 1) * 0 still has undefined
behavior. Undefined behavior is determined by the rules of the
abstract machine *without* any adjustments permitted by the as-if
rule.
This is something I really don't get in the actual C-logic...
>
Using constants that can be determined at compile time is UB here,
despite the '* 0' mathematically indicating an IMO clear semantics,
but using variables is only UB possibly at runtime? [...]
There's an important distinction to make here. Consider this
program:
>
#include <limits.h>
>
int
foo(){
int zero = (INT_MAX+1)*0;
return zero;
}
>
int
main(){
return 0;
}
>
This program does not transgress the bounds of undefined behavior.
To clarify, the comments in my posting were meant to be read as
saying the given text is the entire program, and that it is strictly
conforming with respect to conforming hosted implementations.
(Incidentally, given the rules for freestanding implementations, I'm
not sure that it is even possible for any program to be strictly
conforming with respect to conforming freestanding implementations.
In any case my statements were meant only in the context of hosted
implementations.)
Ok.
[snip]>
Perhaps you mean that this is irrelevant because `foo` is not
invoked, but I see no reason why that need be the case in e.g.
a freestanding environment.
I explained the context of my previous statements above. Sorry for
not saying that in the original message.
>In a hosted environment, I don't>
think anything explicitly prevents `foo` from being called after
`main` returns (though I can't imagine that would happen in real
life; it would be weird if it did).
The semantics described in the ISO C standard don't admit that
possibility.
Could you please point to where it says this, in the C standard?
I cannot find anything that says that arbitrary code cannot run
after `main()` returns, and I don't see how that could possibly
be true.
Whether foo() has external linkage or internal
linkage doesn't change that.
I disagree. There's no possible way for the implementation to
know whether a function with external linkage will be ultimately
invoked or not; consider a system that supports loadable shared
modules. Nothing prevents even this simple program from being
compiled as a shared module, dynamically loaded, the loading
program explicitly searching for and finding the symbol
corresponding to the `foo` function, and invoking it.
Hence, the compiler _must_ treat with UB as written, which is
why `ubsan` inserts trapping code in `foo`.
In your example, `foo` clearly exhibits UB; I think your
argument is whether that has a realized effect or not, since the
UB is not invoked. I'm saying that in general a compiler cannot
possibly know that when it compiles `foo`, and is free to assume
the worst.
Only those actions initiated by
statements in main() are ever elaborated.
This is not true: code can obviously run outside of the bounds
of `main`, for several reasons.
First, there is the issue of static initializers, which you had
mentioned earlier. Not at play here, but it does invalidate
your statement above, as these run "before" main is invoked.
Second, we know that code can run after because `atexit` can be
used to register handlers that will run after it terminates: as
section 5.1.2.3.4 of n3220 says, "a return from the initial call
to the main function is equivalent to calling the exit function
with the value returned by the main function as its argument",
which means that it will run `atexit` handlers. (But, as the
footnote warns, lifetimes of variables with automatic storage
duration have ended in this case in accordance with sec 6.2.4,
since `main` has terminated.)
Third, it is possible to invoke code that may conditionally be
executed, such as signal handlers, in response to external
events. Certainly, `signal(SIGINT, some_handler);` does not
immediately guarantee that `some_handler` is run, but it does
not prevent it from running, either.
Of course, for the second and third points, we must acknowledge
that one might quibble about what it means to say that a program
invokes "actions initiated by statements in main()".
Registering signal and exit handlers is (generally) going to be
something done in as the consequence of an "action initiated by
statements in main()". And subsequent invocation of (say)
`some_handler` in the example above in response to receipt of a
`SIGINT` signal is arguably a consequence of that.
But I'm not sure what _you_ mean by "transgress the bounds of>
undefined behavior" here.
It's a grammatical fine point. I think for present purposes it's
okay to gloss over the distinction, and say this statement may be
read as saying "the program does not have undefined behavior".
Except it does. `foo` is an example of what Regehr calls a
"Type 3" function in https://blog.regehr.org/archives/213.
Also you are discounting time-travel; code not not actually
invoke UB to suffer from it. The mere existence of it can be
enough.
https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=633
Moreover, undefined behavior simply is; the definition from the
C standard does not say that time-traveling "post-modern"
compilers are free to assume and do anything if they observe UB
anywhere in a program.
Here, because `foo` has external linkage, the compiler cannot
know whether `foo` is invoked or not, and I see nothing
preventing it from assuming that the entire program is in error.
In particular, I don't think there is anything that prevents a
compiler from simply emitting `int main(void) { abort(); }`.
>Even more than that, the program is strictly conforming, and must be>
accepted by a conforming implementation.
See above.
>Now let's change the program slightly:>
>
#include <limits.h>
>
int
foo(){
static int zero = (INT_MAX+1)*0;
return zero;
}
>
int
main(){
return 0;
}
>
This program does transgress the bounds of undefined behavior. The
reason for the difference is that in the first program the semantics
of foo() is to evaluate the expression to be stored in 'zero' only
at runtime, whereas in the second program the semantics of foo() is
to evaluate the expression to be stored in 'zero' before program
startup (informally, "at compile time"). What matters is not
whether the offending expression /might/ be evaluated "at compile
time", but whether the offending expression /must/ be evaluated "at
compile time". Only in the second case is undefined behavior
inevitable (and thus it does not occur in the first program).
>
Fine point: strictly speaking, I believe the C standard allows even
the second program to complete translation phase 8 successfully, and
for any offending behavior to occur only when we actually try to run
the program. To say that another way, there is no requirement that
possible nasal demons be made manifest at any point before an actual
attempted execution. On the other hand, because that possibility is
there lurking in the background, there is no requirement that the
program be accepted, and could be rejected by a conforming compiler.
Indeed. Further, I believe that the same is true for the first
program, as well.
It isn't. In the first program the offending expression is never
evaluated, because foo() is never called.
See above.
Of course, I don't think any of this would _actually_ happen,
and if it did, one should take the compiler that does it and
toss it in the trash. But I don't think it's prohibited,
either; such is one of the consequences of an informal
specification like the C standard. Time-travel is especially
pernicious in post-modern compilers.
- Dan C.
Les messages affichés proviennent d'usenet.