[intro.object] Implicit object creation UB bypasses observable checkpoints

[Eisenwave]

Reference (section label): [intro.object]

Issue description

int main() {
    unsigned char buffer[1]; // #1, undefined behavior
    std::println("..."); // #2, intended to be observable checkpoint, but also UB
    std::unreachable(); // #3, also UB
}

#2 is only an observable checkpoint without #1, so implementations are permitted to optimize it out. That is because the implicit object creation of zero or more objects inside buffer only takes place "if doing so would result in the program having defined behavior" ([intro.object] paragraph 11), and otherwise, the whole program has undefined behavior. Since #3 unconditionally gives this program undefined behavior, implicit object creation does not take place, and #1 has undefined behavior.

In other words, the future undefined behavior from #3 travels back into the past to #1, ignoring the observable checkpoint at #2.

Suggested resolution

Change [intro.object] paragraph 11 as follows:

Some operations are described as implicitly creating objects within a specified region of storage.
For each operation O that is specified as implicitly creating objects, that operation O implicitly creates and starts the lifetime of zero or more objects of implicit-lifetime types ([basic.types.general]) in its specified region of storage if doing so would result in the program having defined behavior. If no such set of objects would give the program defined behavior, the behavior of the program is undefined. O becoming part of the defined prefix of the execution; otherwise, the behavior of O is undefined.
If multiple such sets of objects would give the program O defined behavior, it is unspecified which such set of objects is created.

[Eisenwave]

Also note that upon closer inspection

If no such set of objects would give the program defined behavior, the behavior of the program is undefined.

Is vacuous. We're basically saying:

If there is no defined behavior, the behavior is undefined.

[frederick-vs-ja]

I guess it's more robust to specify that O never causes UB itself. I'd like to introduce something like "well-defined creation set" (for each O) that is "set of sets of implicitly created objects that are still able to make the program execution well-defined", and say that an operation that reduces the well-defined creation set to empty is undefined.

[Eisenwave]

Looking at https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0593r6.html, I am not convinced you can just say that implicit object creation is always well-defined (and presumably, at worst, creates an empty set of objects). Also note that it is well-defined right now for implicit object creation to create an empty set of objects, if that gives the program well-defined behavior, so this idea of

and say that an operation that reduces the well-defined creation set to empty is undefined.

... would add UB where there currently is none, unless you mean that it would turn the set of possible sets into the empty set of sets.

A key issue is that std::malloc returns a pointer to a suitable created object, and if implicit object creation fails, it's unclear what that would be. != nullptr wouldn't really work if std::malloc succeeds in allocation, but gives you a pointer to ... no object?

Anyhow, that appears like a pretty large deviation in wording strategy that would have a large blast radius, so as magical as the current wording is, we shouldn't change it too much. Feel free to make a paper which overhauls this wording in general.

[frederick-vs-ja]

Also note that it is well-defined right now for implicit object creation to create an empty set of objects, if that gives the program well-defined behavior, so this idea of

and say that an operation that reduces the well-defined creation set to empty is undefined.

... would add UB where there currently is none, unless you mean that it would turn the set of possible sets into the empty set of sets.

Hmm, I meant that "the empty set of implicitly created objects" is possibly a single element of the well-defined creation set, so that latter set is not empty in such a case. UB won't be added, and will just be delayed, if any.

(The well-defined creation set at some point of execution might be described as {{}, {o1}, {o2}, {o1, o3}, ...} where oN are implicitly created objects, and a further operation will possibly remove elements from the set.)

A key issue is that std::malloc returns a pointer to a suitable created object, and if implicit object creation fails, it's unclear what that would be. != nullptr wouldn't really work if std::malloc succeeds in allocation, but gives you a pointer to ... no object?

Agree on this. I don't know there's any possibility that an execution is well-defined only if no object is implicitly created at the start of the allocated storage. Perhaps it's OK to say this never happens when a suitable created object is mentioned, and there's always at least one object implicitly created at the start.

When the storage is pre-existing, IMO we need to allow implicit object creation to create zero object, in order not to end the lifetime of existing objects in that storage.

[zygoloid]

[Edit: incorporate some suggestions from Eisenwave]

I think in the new world of observable checkpoints, the behavior we want is something like:

In [intro.object]/11:

For each operation O that is specified as implicitly creating objects, that operation O implicitly creates and starts the lifetime of zero or more objects of implicit-lifetime types ([basic.types.general]) in its specified region of storage if doing so would result in the program having defined behavior chosen to maximize the defined prefix of the execution ([intro.abstract]). If no such set of objects would give the program defined behavior, the behavior of the program is undefined. [ Note: If multiple such sets of objects would give the program defined behavior result in a maximal defined prefix for the execution, it is unspecified which such set of objects is created. -- end note ]

And similarly in [intro.object]/12.

Then after [intro.abstract]/7:

The defined prefix of an execution comprises the operations O for which for every undefined operation U there is an observable checkpoint C such that O happens before C and C happens before U.
[...]
[Note 3: An implementation can issue a diagnostic if it can determine that erroneous behavior is reachable under an implementation-specific set of assumptions about the program behavior, which can result in false positives. — end note]

Certain operations are specified as making a choice to maximize the defined prefix of the execution. The behavior of all such operations in that execution is such that the defined prefix P of the execution is not a proper subset of the defined prefix that would result from any other choices, but the choices are otherwise unspecified.

[Eisenwave]

@zygoloid I'm not convinced that we should be putting "it is unspecified which such set of objects is created" into a note, at least not if this moves the only "unspecified" for this part of wording out of normative wording. I like the overall strategy though.

Normally when the implementation makes choices, we say whether that choice is unspecified or implementation-defined, so it seems like if you sprinkle in "unspecified" somewhere into the definition of "maximize the defined prefix", that really ties the change together.

Also note that it's "defined prefix of an execution", not "defined prefix of the program"; we should be consistent about that.

[zygoloid]

@zygoloid I'm not convinced that we should be putting "it is unspecified which such set of objects is created" into a note, at least not if this moves the only "unspecified" for this part of wording out of normative wording. I like the overall strategy though.

Normally when the implementation makes choices, we say whether that choice is unspecified or implementation-defined, so it seems like if you sprinkle in "unspecified" somewhere into the definition of "maximize the defined prefix", that really ties the change together.

Good point. My intent was that the [intro.abstract] wording leaves the precise choice implicitly unspecified, but being explicit seems better. I've edited my suggestion to explicitly call that out.

Also note that it's "defined prefix of an execution", not "defined prefix of the program"; we should be consistent about that.

Fixed, thanks.