[intro.abstract] Unspecified behavior and the corresponding possible executions

[xmh0511]

Full name of submitter (unless configured in github; will be published with the issue): Jim X

int main(){
   int i = 0;
   for(int c = 0;c <10;c++){
     char b = *(char*)&i;
     if (b == 0){
         // big endian
     }else{
       // little endian
     }
   }
}

As discussed in https://github.com/cplusplus/CWG/issues/261#issuecomment-1467537017, we say the behavior is unspecified, [intro.abstract] p3 says

Certain other aspects and operations of the abstract machine are described in this document as unspecified (for example, order of evaluation of arguments in a function call ([expr.call])). Where possible, this document defines a set of allowable behaviors. ... An instance of the abstract machine can thus have more than one possible execution for a given program and a given input.

[intro.abstract] p5 says

A conforming implementation executing a well-formed program shall produce the same observable behavior as one of the possible executions of the corresponding instance of the abstract machine with the same program and the same input.

Because unspecified behavior may have more than one possible execution, so, a conforming implementation can produce different observable behavior between every loop?

Suggested Resolution

We may need to say whether a consistent observable behavior will be given in each evaluations that contain the unspecified/implementation-defined behavior.

[jensmaurer]

a conforming implementation can produce different observable behavior between every loop?

In principle, yes. (For example, order of evaluation of arguments could be different depending on inlining and loop peeling.)

For your particular example, you're looking at the object representation of i, which is not supposed to be unspecified behavior. We're lacking specification in that area, though. See https://wg21.link/p1839 .

[xmh0511]

In principle, yes. (For example, order of evaluation of arguments could be different depending on inlining and loop peeling.)

So is it likewise for implementation-defined behavior if there is no other requirement in the document? As discussed in https://stackoverflow.com/questions/3296523/is-implementation-defined-behavior-required-to-be-consistent-between-runs-in-c, namely, the parameter of the abstract machine determined by the implementation is itself a function.

[jensmaurer]

So is it likewise for implementation-defined behavior if there is no other requirement in the document?

Since implementation-defined behavior is required to be documented, the implementation should tell you what happens. Note that an implementation still needs to be conforming; for example, sizeof(T) is expected to give the same answer for any given T everywhere in your program where T is complete. (I think there's a bit of missing wording for this, maybe.)

[xmh0511]

For unspecified behavior, from your confirmation, the wording may be good enough to convey the intent, without misreading.

For the implementation-defined behavior:

(I think there's a bit of missing wording for this, maybe.)

together with the misreading by other readers, we may have some room to improve the wording to make the intent clearer.

[jensmaurer]

I was referring specifically to the sizeof(T) value, not to "implementation-defined behavior" in general.

As usual, specific suggestions for wording changes are welcome.

[xmh0511]

I was referring specifically to the sizeof(T) value, not to "implementation-defined behavior" in general.

Purely from the current wording:

These constitute the parameters of the abstract machine. Each implementation shall include documentation describing its characteristics and behavior in these respects.

Assume a hypothetical implementation whose document describes an operation that is defined as implementation-defined behavior by the standard as the following:

The result is x if it is executed on Monday and y otherwise.

This is the described characteristic and behavior. For the operation, the corresponding instance will produce different behaviors varying on time. This sounds like a correct interpretation according to the current wording.

[xmh0511]

In C standard, it defines implementation-defined behavior, https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf#subsection.3.4.1:

unspecified behavior where each implementation documents how the choice is made

We cloud say:

Certain aspects and operations of the abstract machine are described in this document as implementation-defined, which is the same as the unspecified behavior except that the implementation shall include documentation to specify which one choice from the more than one possible execution for a given program and a given input is.

[jensmaurer]

The result is x if it is executed on Monday and y otherwise.

And that's fine as long as the other rules of C++ are satisfied. There does not need to be a single choice (often, there is an unbounded set of choices).

[xmh0511]

And that's fine as long as the other rules of C++ are satisfied.

Is it true even though the result can be different in every evaluation of the expression(containing the implementation-defined behavior), as long as otherwise parts are all satisfied?

[jensmaurer]

I'd tentatively say "yes", but as I said earlier, a lot of implementation-defined properties have stability expectations (for example, when there are types involved).

But, for instance, something like [locale.statics] talks about effects on the C locale, and I think it's totally conforming (although probably not really useful) if an implementation says "I'll change the C locale on Tuesday before noon only".

[xmh0511]

Thanks for your confirmation. Since the current wording can convey the intent, there seems to be no issue here.