4

The following code appeared in this question:

int k = 0;
while(+(+k--)!=0)
    k=k++;

The statement k=k++ would unquestionably invoke undefined behavior if executed because k is both read and written without a sequence point. However, in the above code the body of the loop is never entered so the offending statement is not executed.

The question is does this cause the whole program to be undefined anyway? In a situation such as this:

if (x != NULL)
    *x = 4;

The statement *x = 4; would only cause undefined behavior if x is NULL. But in the case of k=k++ it is always undefined.

So the question is how would a compiler be expected to handle code such as this? Does it automatically invalidate the entire program, even if the statement doesn't execute?

Steve Summit
  • 45,437
  • 7
  • 70
  • 103
dbush
  • 205,898
  • 23
  • 218
  • 273
  • I think the compiler might infer some weird conclusions about `k` that will actually make this loop to be executed. – Eugene Sh. Nov 01 '19 at 15:10
  • Wouldn't a smart compiler not just optimise away the whole loop, with out even looking into its code? – alk Nov 01 '19 at 15:12
  • @alk Perhaps in this case but not in general, for example if `k` was passed as a parameter. – dbush Nov 01 '19 at 15:13
  • 1
    [Can code that will never be executed invoke undefined behavior?](https://stackoverflow.com/q/18385020/1275169) – P.P Nov 01 '19 at 15:15
  • The UBs in your examples are of different "type". The `k++` one is a "compile-time" UB as it is not known what code will be emitted. The UB of NULL dereferencing is a "run-time" UB - as it is not known how the environment will react to this. I would say "compile-time" UB is always UB (because it's "result" is happening always). – Eugene Sh. Nov 01 '19 at 15:16
  • my brain is broken before that point... what is this `+(+k--)` ? – Grady Player Nov 01 '19 at 15:16
  • 2
    @GradyPlayer Same as `k--` as far as I can tell... – Eugene Sh. Nov 01 '19 at 15:17
  • wow, I guess that is useful on wacky macro expansion... – Grady Player Nov 01 '19 at 15:20
  • 2
    @EugeneSh. The C standard doesn't use such notions. There is only one kind of UB. – n. m. could be an AI Nov 01 '19 at 15:21
  • For the `k++` example, I suppose the question is, when is a side effect not a side effect? 5.1.2.3 paragraph 2 seems to imply that side effects result from evaluation rather than from mere presence. I.e. UB occurs at the point of evaluation. – Ian Abbott Nov 01 '19 at 15:22
  • @n.m I know, this is my intuition. But the dereferencing in the code above is not UB for sure. Are you saying that `k++` one is not UB as well? – Eugene Sh. Nov 01 '19 at 15:25
  • @IanAbbott Side effect != UB. Side effect might present at the point of evaluation, But UB might present elsewhere – Eugene Sh. Nov 01 '19 at 15:32
  • 1
    @EugeneSh. The notion of UB is only applicable to entire programs, not to isolated fragments. `k = k++` is an isolated fragment and so we cannot talk about it having or not having UB. `k = k++` in context of the entire program does not invoke any side effects, because it's dead code, so no UB here. – n. m. could be an AI Nov 01 '19 at 15:32
  • @n.m. UB is not necessarily related to side effects but to the result of compilation/optimization. Naming a variable `_a` has UB as well, but it is definitely doesn't have any side effects during *execution*. – Eugene Sh. Nov 01 '19 at 15:34
  • @EugeneSh. Yes, but I was assuming this in the context of 6.5 paragraph 2. – Ian Abbott Nov 01 '19 at 15:34
  • @EugeneSh. We are talking about a specific kind of UB (defined in 6.5/2) which is a side effect unsequenced with certain other things. If there's no side effect, then this kind of UB does not occur. – n. m. could be an AI Nov 01 '19 at 15:34
  • @n.m. Let me cite yourself from above: *There is only one kind of UB* – Eugene Sh. Nov 01 '19 at 15:35
  • @EugeneSh. Bad wording on my part, substiture "case" for "kind". The standard enumerates all cases in appendix J.2 (" The behavior is undefined in the following circumstances:...") There is no classification into "run time" and "compile time" UB, just a flat list of cases. (There is no "compile time" in the C standard at all). – n. m. could be an AI Nov 01 '19 at 15:38

0 Answers0