[2026-06 CWG Motion 2] P3596R3 Undefined Behavior and IFNDR Annexes by notadragon · Pull Request #9107 · cplusplus/draft

notadragon · 2026-06-13T20:33:49Z

Fixes #9069
Also fixes cplusplus/papers#2623

This is from the branch from which the paper was generated, with a small number of editorial changes already made:

Most notable, after rendering the standard the annex titles were very large and wrapping to multiple lines. After discussion, Jens and I shortened them by removing "Enumeration of" from each one.
One set of comments was fixed to use "IFNDR" the way the rest of the annex does instead of the (comma-less) "ill formed no diagnostic required"
One bug that was discovered during wording review of another paper was fixed, but that entry will also be removed when that paper lands in a later motion.
The \lastcorechapter macro was used where it was supposed to be used because my paper rendering couldn't handle that when the P paper was generated.

shafik

Finished UB section.

shafik · 2026-06-19T22:24:45Z

+\end{codeblock}
+\end{example}
+
+\ubdescription{conv.fpint.float.not.represented}


Super minor but I think this one should be swapped w/ conv.fpint.int.not.represented b/c in 7.3.11 we have E.3.8 first and then E.3.7 but again super minor nit.

will rearrange.

shafik · 2026-06-19T22:31:58Z

+
+\pnum
+Evaluating a \keyword{dynamic_cast} on a reference that
+denotes an object (of polymorphic type) of the wrong type or an object


Suggested change

denotes an object (of polymorphic type) of the wrong type or an object

denotes an object (of polymorphic type) of the similar type or an object

I am not sure but looking at the core wording, I think that is more correct?

"of the similar type" is wrong, similar type would be fine. "wrong" type could be interpreted broadly as "any type that is wrong for doing this" but we can be more precise and say "of a type that is not similar" . I will change to that.

shafik · 2026-06-19T22:50:30Z

+\pnum
+\begin{example}
+\begin{codeblock}
+struct S {


You don't indicate the UB in the example and why didn't you use the simpler example from 7.6.6? Maybe this was my original example?

i will compact this example slightly and add a comment about the UB. Not sure who the example dates back to (probably you). I would rather not rewrite examples entirely in this phase so will leave switching to clearer/simpler examples for followup efforts.

shafik · 2026-06-19T22:53:08Z

+\ubdescription{expr.assign.overlap}
+
+\pnum
+Overlap in the storage between the source and destination may result in undefined behavior.


Should we be using may here?

shafik · 2026-06-19T23:10:11Z

+\ubdescription{class.base.init.mem.fun}
+
+\pnum
+It is undefined behavior to call a member function before all the \grammarterm{mem-initializer}s for base classes have completed.


It looks like there are two contracts cases added that we are missing. This feels minor and we can add afterwards too.

I am prepping a PR with new/missing entries and any entries that need major updating after all of the Brno motions land, I will make note to include this in that PR (and the paper that will be generated from that PR). I think it should wait until after all of the Brno motions land.

jensmaurer · 2026-06-21T05:41:44Z

@notadragon, please squash all commits into the first one; we don't need the details of the genesis preserved for posterity.

jensmaurer · 2026-06-21T05:43:11Z

@notadragon, do we have "ubx" as part of a visible label in the Annex headings now? We shouldn't; those visible labels should be "ub:something". (Similarly with ifndrx, if any).

shafik

Finished reviewing IFNDR annex. Really minor comments. I think we are in good shape here.

shafik · 2026-06-21T22:12:08Z

+\ifndrdescription{module.unit.named.module.no.partition}
+
+\pnum
+Having multiple primary module interface units


I am not sure this description matches what the wording says but I may just not be reading it correctly.

The wording defines "primary module interface unit" and says, effectively, "A named module shall contain one module interface unit that meets that definition, no diagnostic required". As far as I can tell that's what the annex entry is saying as well, though i'm happy to adjust if it's wrong or there's clearer wording. Leaving this as-is for now.

notadragon · 2026-06-22T14:40:55Z

@notadragon, do we have "ubx" as part of a visible label in the Annex headings now? We shouldn't; those visible labels should be "ub:something". (Similarly with ifndrx, if any).

No, I swapped which label is "ub:" and which is "ubx:", and I also made the "stable names" shown in the annex start with "ub:" and ifndr:.

Here's some screenshots of my locally built copy of the standard for review:

notadragon · 2026-06-22T16:37:05Z

@jensmaurer @shafik I've addressed, I believe, all of your comments.

shafik · 2026-06-22T16:55:00Z

@jensmaurer @shafik I've addressed, I believe, all of your comments.

Thank you so much for all this work to get the annexes landed in the draft! I am happy with direction in your replies.

Editorial notes: * minor adjustments to comment placement, capitalisation and punctuation * punctuation fixes * rephrased some colloquialisms (like "we" and "kick off") * dropped an unhelpful and imprecise comment Example 2 of [ub:expr.add.out.of.bounds]

The original wording was somewhat colloquial and needlessly inconsistent in places.

Currently, the example contains no explanations of how it demonstrates the behaviour in question.

frederick-vs-ja · 2026-07-15T03:49:06Z

+  new int[-(int)sizeof(T)];     // IFNDR, the size of the allocation is required to be greater
+                                // than zero but can never be


This example seems to be well-formed per the analysis in #6055. Looks like that we incorrectly copied a legacy example.

We've landed this motion, but I am going to do a pass at a followup PR to clean up any discovered issues/gaps and to reconcile with the other motions that landed in Brno. I'll try to address this in that PR. (Though recommended alternative examples are welcome.)

Maybe we can adopt the proposed example in #6062.

new decltype((void)T{}); // IFNDR, the type of the object to create is never valid

frederick-vs-ja · 2026-07-15T03:49:52Z

+\begin{codeblocktu}{Translation unit \#2}
+inline void f() {}          // OK, same as \#1
+inline void g() {;}         // IFNDR, different sequence of tokens than \#2
+inline void h() {[]{}();}   // IFNDR, closure has different type than \#3


Such 2 definitions of h seem to be well-formed per CWG2300. Perhaps we should change to use default arguments.

Agreed, this is also not right, i will try to include a fix in the followup PR/paper. (Concrete alternative examples are welcome)

I think we can just change the case to inline void h(void (*)() = []{}()) {}.

I think we can just change the case to inline void h(void (*)() = []{}()) {}.

Note that the example added in CWG2300 is:

inline void g(bool cond, void (*p)() = []{}) { if (cond) g(false); }

I believe it is necessary to include the recursive call, if it was not then it presumably would have been omitted.

I had gone with a local function declaration being called, but i think the recursive call is better. I will update it. (See https://isocpp.org/files/papers/D4284R0.pdf for the fixes i intend to land)

Halalaluyafail3 · 2026-07-16T05:56:48Z

+int _z; // IFNDR, \tcode{\_z} is reserved because it starts with \tcode{\_} at global scope
+
+int main() {
+    int __x;    // IFNDR, \tcode{\_\_x} is reserved because it starts with \tcode{\_\_}
+    int _Y;     // IFNDR, \tcode{\_Y} is reserved because it starts with \tcode{\_} followed by a capital letter
+    int x__y;   // IFNDR, \tcode{x\_\_y} is reserved because it contains \tcode{\_\_}
+}


Is there a reason these underscores have backslashes before them? It seems inconsistent since this is the only place that does it.

because underscores in LaTeX are stupid. These render the same way either way _, so removing them would be purely editorial. (I will remove them in the PR for https://isocpp.org/files/papers/D4284R0.pdf).

It seems to cause issues with rendering on https://eel.is/c++draft/ifndr:lex.name.reserved.

tkoeppe · 2026-07-16T13:58:10Z

We have macros to produce double underscores if that's an issue...

notadragon · 2026-07-16T14:12:08Z

We have macros to produce double underscores if that's an issue...

The standard renders fine without the _s, we can just remove them. I only put them there out of personal habit. (Though this also sounds like it is triggered by an eel.is problem, not an us problem :) )

notadragon mentioned this pull request Jun 13, 2026

[2026-06 CWG Motion 14] P3424R2 Deallocation Functions with Throwing Exception Specification Are Ill-formed #9081

Closed

eisenwave added this to the post-2026-06 milestone Jun 14, 2026

shafik reviewed Jun 19, 2026

View reviewed changes

shafik reviewed Jun 22, 2026

View reviewed changes

notadragon force-pushed the ub-ifndr-cwgreview1 branch from c26a110 to 3e05f52 Compare June 22, 2026 16:36

tkoeppe force-pushed the ub-ifndr-cwgreview1 branch 4 times, most recently from 1ef0f08 to 9d9e262 Compare July 11, 2026 23:56

joshuaberne and others added 4 commits July 12, 2026 10:53

[ub.general] Reorder list of phrases

9d7ff81

[ub] Rephrase "is undefined behavior", restructure sentences.

b7f6522

The original wording was somewhat colloquial and needlessly inconsistent in places.

[ifndr:temp.point.diff.pt.diff.meaning] Add comments to example.

f0a1a4e

Currently, the example contains no explanations of how it demonstrates the behaviour in question.

tkoeppe force-pushed the ub-ifndr-cwgreview1 branch from 40d7454 to f0a1a4e Compare July 12, 2026 09:53

tkoeppe merged commit ea6540b into cplusplus:main Jul 12, 2026
2 checks passed

frederick-vs-ja reviewed Jul 15, 2026

View reviewed changes

Halalaluyafail3 reviewed Jul 16, 2026

View reviewed changes

	denotes an object (of polymorphic type) of the wrong type or an object
	denotes an object (of polymorphic type) of the similar type or an object

		new int[-(int)sizeof(T)]; // IFNDR, the size of the allocation is required to be greater
		// than zero but can never be

Uh oh!

Conversation

notadragon commented Jun 13, 2026

Uh oh!

shafik left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jensmaurer commented Jun 21, 2026

Uh oh!

jensmaurer commented Jun 21, 2026

Uh oh!

shafik left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

notadragon commented Jun 22, 2026

Uh oh!

notadragon commented Jun 22, 2026

Uh oh!

shafik commented Jun 22, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

frederick-vs-ja Jul 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tkoeppe commented Jul 16, 2026

Uh oh!

notadragon commented Jul 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

frederick-vs-ja Jul 15, 2026 •

edited

Loading