P2795 R5 Erroneous behaviour for uninitialized reads

[ben-craig]

P2795R0 Correct and incorrect code, and “erroneous behaviour” (Thomas Köppe)

[erichkeane]

EWG discussed this paper during the February 10th, 2023 morning session in Issaquah. The following poll was taken:

EWG is interested in adding the concept of erroneous behavior as an alternative to undefined behavior, as proposed in D2795R0.

SF	F	N	A	SA
11	13	10	7	1

Result: Not Consensus

[ben-craig]

D2795R0

SG23 (Safety and Security) saw this paper on Feb 9 in Issaquah.

Presenter: Thomas Köppe Chair: Roger Orr, Ben Craig Minutes: Mungo Gill

POLL: Do we want the standard to be able to speak in terms of erroneous behavior in addition to undefined behavior

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
14	18	10	7	1

Outcome: Weak consensus

SA: My vote would be altered if I saw concrete example in the standard were undefined would turn to erroneous. Worried we will add complexity without solving a problem

A: Need more examples. Need examples of what compiler should do instead.

[erichkeane]

EWG discussed D2795R1 on Thursday Morning in Varna. The following poll was taken:

EWG approves D2795R1, which changes uninitialized automatic variable use to be erroneous behavior, and forwards it to CWG.

SF	F	N	A	SA
16	21	7	2	3

Result: Consensus

Note: The chair failed to include "for inclusion in C++26" in the poll wording, however believes that this was a well understood consequence of the poll, so does not require re-polling.

[jensmaurer]

CWG 2023-06-15: Reviewed; needs updates.

[jensmaurer]

CWG 2023-06-16: Reviewed; wording looks good.

Consensus: CWG is unhappy with forwarding this paper without an integrated opt-out mechanism for this particular application of "erroneous behavior".

We also noticed that this feature is a potential performance pessimization even if a constructor fully initializes an object, because now the initialization of all padding is required.

[wg21bot]

P2795R1 Erroneous behaviour for uninitialized reads (Thomas Köppe)

[wg21bot]

P2795R2 Erroneous behaviour for uninitialized reads (Thomas Köppe)

[wg21bot]

P2795R3 Erroneous behaviour for uninitialized reads (Thomas Köppe)

[jfbastien]

EWG reviewed this on Kona on Monday.

Poll:forward P2795r3 “Erroneous behaviour for uninitialized reads” to CWG for inclusion in C++26, but also provide EB for all automatic variables (including function parameters and temporary objects).	SF	F	N	A	SA
6	14	4	3	2

Consensus.

Poll: forward P2795r3 “Erroneous behaviour for uninitialized reads” to CWG for inclusion in C++26 as is.	SF	F	N	A	SA
8	7	7	4	5

Not consensus.

[jensmaurer]

@jfbastien , assuming the assignment to LWG was in error. Assigning to CWG instead.

[jensmaurer]

CWG 2023-11-08: Reviewed; needs updates.

[jensmaurer]

CWG 2023-11-09: Reviewed.

[jensmaurer]

CWG 2023-11-10: Reviewed; needs updates.

[jensmaurer]

This has a small bit of library wording that is unlikely to be affected by further CWG review, but (of course) needs to be seen by LWG.

[wg21bot]

P2795R4 Erroneous behaviour for uninitialized reads (Thomas Köppe)

[jensmaurer]

CWG 2024-03-19: Reviewed D2795R5 and approved for Saturday's plenary vote.

Still outstanding: LWG approval for the library parts.

[jensmaurer]

CWG 2024-03-21: Reviewed LWG updates of D2795R5; needs re-review of LWG changes.

Question to EWG: This feature does not change the net "undefined behavior" situation for uninitialized variables of bool and pointer types (or uninitialized members of that type), because the initialization with erroneous values can't guarantee a valid value for those types. Is that accepted?

[erichkeane]

EWG discussed this during the Friday Morning session in Tokyo. The following poll was taken:

Poll: D2795R5: Erroneous behavior for uninitialized reads: EWG agrees that EB may create values which later trigger UB, for example an EB read of a pointer has a defined value but dereferencing the pointer may then be UB.

SF	F	N	A	SA
5	7	3	0	0

Result: Consensus

[jensmaurer]

CWG 2024-03-22: Approved for Saturday's plenary straw polls.

[wg21bot]

P2795R5 Erroneous behaviour for uninitialized reads (Thomas Köppe)

[ByteEater-pl]

A change from the earlier revision P2795R0 is that the permission for an implementation to reject a translation unit “if it can determine that erroneous behaviour is reachable within that translation unit” has been removed: Richard Smith pointed out that such a determination is not generally possible. Any attempt to reject any erroneous behaviour at all would most likely have false positives

While the first sentence is true (a simple reduction from the halting problem can be shown), I find the second fragment surprising. There can be and indeed are such attempts successfully performed by compilers of other languages, by proof assistants and by tools used to analyze similar situations for software security purposes. Both deterministic and nondeterministic. None of them can be sound and complete, i.e. have neither false positives, nor negatives, but a wide span of cases (and quickly growing nowadays with advances in theory and practice of the field) can be usefully, and retaining soundness, statically determined.

Without allowing implementations to reject translation units based on its ability to prove it exhibits erroneous behaviour, the result is that erroneous behaviour wouldn't differ from defined behaviour in any hard way. Just an encouragement to emit warnings. Which can be emitted for defined behaviour too whenever the implementation considers something smelly. And thus the erroneous behaviour presumably will be treated as a feature and relied upon more than intended.

In summary, the change reduces the value of the proposal to almost nothing, it doesn't seem well argued (although I haven't acquainted myself with Richard Smith's original statement), and I propose to revert it.

[jensmaurer]

@ByteEater-pl , this issue tracker is for administrative tracking of in-flight WG21 papers. Any technical discussion should happen in the appropriate venues, e.g. on the committee reflectors or during committee meetings. Also note that the paper in question has been approved for the C++ working draft; if you wish to argue for it to be reverted, please write a paper for WG21 to consider, containing strong rationale.