(Jens and Gašper, please correct/expand anything below.)

 

Hi everyone, this is an update on progress on the UB/IFNDR work, and a request for this group’s feedback on the questions below.

 

The first step is to document the current UB/IFNDR we already have: tag all instances and create Annexes. Shafik (thanks!) with help from some others (especially Timur and Josh, thanks!) has a pretty complete first pass as a draft PR here for explicit cases of IFNDR (25 cases) and UB (63 cases):

 

               https://github.com/cplusplus/draft/pulls?q=is%3Apr+is%3Aopen+label%3Aub-ifndr

 

The goal is to turn this into a comprehensive submission to CWG. Two major next substeps:

 

 

A) Before it’s ready for CWG we need to eradicate all mentions of normative-looking words: “shall”, “may”, “might”, “could”, and “should”.

 

Using the example \ubxref{expr.delete.dynamic.type.differ} as a test for what we want to do:

 

* Current PR says:
If the static type of the object to be deleted is different from its dynamic type and the selected deallocation function (see below) is not a destroying operator delete, the static type shall be a base class of the dynamic type of the object to be deleted and the static type shall have a virtual destructor or the behavior is undefined.

 

* Possible rewrite 1 – just avoid normative words:
Issue: Deleting an object whose static type is different from its dynamic type and the selected deallocation function is not a destroying operator delete, and:
* the static type is not a base class of the dynamic type of the object to be deleted; or
* the static type does not have a virtual destructor.

 

* Possible rewrite 2 – condensed paraphrase:
Issue: Deleting an object of type T, where the operand of the delete-expressions is of type "pointer to U", for certain combinations of T and U.

 

Jens suggested that style 2 may be better: It’s less likely to become inconsistent if we ever change the normative rule in the future. It avoids trying to exactly reproduce the rule (we have cross-references for that).

 

Call for feedback: What do you think? Do we prefer style 1, or style 2, or something else?

 

If there’s deafening silence, we’ll interpret that as unanimous consent for “Jens is always right, do style 2.” 😊

 

 

B) Also, expand the PR to cover the cases of UB/IFNDR that are not explicit.

 

For the cases that are not explicit, we want to:

* follow the pattern to add { \ubdef \ubxref, { \ifndrdef \ifndrxref } tags for them too
* PLUS propose editorial wording changes to make the case explicit
* and open Core issues for these (however Jens prefers this to be done).

 

Call for volunteers to look for implicit cases in selected clauses: Please reply if you would like to volunteer to look at a particular clause and see if you can find some non-explicit UB/IF-NDR.

 

 

Thanks!

 

Herb