[Contero]

> Consider the following example:

  if (cond) {
    A[1] = X;
  } else {
    A[0] = X;
  }

> A total license implementation could determine that, in the absence of any undefined behavior, the condition cond must have value 0 or 1.

> If undefined behavior occurred somewhere in the integer arithmetic of cond, then cond could end up evaluating to a value other than 0 or 1

I don't even follow this very first example. Neither C nor C++ have any requirement that their condition statements be given 0 or 1.

In C:

> the first substatement is executed if the expression compares unequal to 0.

In C++:

> The value of a condition that is an expression is the value of the expression, contextually converted to bool

Where conversion to bool is defined as:

> A zero value, null pointer value, or null member pointer value is converted to false; any other value is converted to true

I'm sure such a thing could occur if cond had a boolean type but contained uninitialized data. That would be similar to the situation talked about in this link: https://markshroyer.com/2012/06/c-both-true-and-false/

[Pinus]

I, too, scratched my head over that for a while, and eventually realized that I had probably misunderstood what the authors are trying to say.

I think what they mean is that if the compiler has analyzed the code, not shown in the example, that comes before the if statement, and concluded that unless something undefined happens, cond can only be 0 or 1, then it can optimize out the condition.

They are not saying that the code actually shown is enough to conclude that cond must be 0 or 1.

[Contero]

Yeah re-reading the wording now I think you're right. It's this part that throws me off:

> could determine that, in the absence of any undefined behavior

"could determine that" based on the code example shown

vs

"could determine that" based on static analysis performed on some preceding code

It would have been a lot easier to wrap my head around if it were an example where cond could be 0 or 4 or something along those lines. It would really underscore the compiler's desire to reuse the cond as the index.