search

cplusplus / CWG

Core Working Group
23 stars 7 forks source link

[intro.abstract] p2 The choice of the implementation-defined behavior is not a casual decision #450

Open xmh0511 opened 8 months ago

xmh0511 commented 8 months ago

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

[intro.abstract] p2 says:

Certain aspects and operations of the abstract machine are described in this document as implementation-defined (for example, sizeof(int)). These constitute the parameters of the abstract machine. Each implementation shall include documentation describing its characteristics and behavior in these respects. Such documentation shall define the instance of the abstract machine that corresponds to that implementation (referred to as the “corresponding instance” below).

The rule sounds like the implementation can choose any behavior it wants when the document says the behavior is implementation-defined. However, as discussed in https://github.com/cplusplus/CWG/issues/352#issuecomment-1621176512, https://github.com/cplusplus/CWG/issues/352#issuecomment-1621878990

When we are in an implementation-defined domain, the implementation should also need to obey that the chosen behavior does not otherwise violate other semantics or rules defined in this document.

Suggested Resolution

The intent of the wording should mean, that the implementations are permitted to give multiple behaviors for an implementation-defined construct in a single program when the construct is multiple executed, however, provide that the multiple behaviors the implementation chooses shouldn't otherwise violate other rules or requirements. Otherwise, the chosen behavior should remain consistent in the program.

Reword the rule to make this meaning clearer.

t3nsor commented 7 months ago

Consider http://eel.is/c++draft/conv.lval#3.3 What is the range of behaviors that you think the standard should allow in this case? Presumably we intend to allow the implementation to terminate the program. The implementation could also print an error message first and then terminate the program, and the message that it prints could depend on the current state of the program. What would stop the implementation from doing something more complicated? Perhaps a hostile implementation could say that it defines the behavior to be as if the program continued executing but with one specified bit of its memory flipped. Presumably no real implementation would do that, but I don't see how we can draw a line. As long as the implementation documents its behavior, that's sufficient to distinguish it from undefined behavior, and I don't think we can specify it further.