Hi Jens,

Is this intended to cover just the core language or would it also include
the library wording?

There are plenty of library bits that represent programming errors that
might not be UB but may be IFNDR, e.g. using a type that models invocable
but not regular_invokable where the latter is required. I'm not fluent
enough in standardese to tell if these would be IFNDR (or some third class
of undetectable error).

Thanks,
Fraser

On Fri, 10 Nov 2023 at 13:08, Jens Maurer via SG23 <sg23_at_[hidden]>
wrote:

> Hi,
>
> An ad-hoc group met yesterday at 5pm HST to discuss
> the procedures and shape of a catalog of undefined behavior
> and IFNDR.
>
> Results:
>
> - The goal is to have two distinct lists, one with undefined
> behavior and one with IFNDR, presented as one or two Annexes
> within the Working Draft.
>
> - Entries will be grouped in subclauses according to the
> clause structure of the standard (cf. Annex C).
>
> - Each entry is a single instance of undefined behavior
> as called out in the main body of the text. Implicit undefined
> behavior is first made explicit in the main body of the text,
> at which point it can be added to the Annex.
>
> - Each entry has the following structure:
> * title showing a concise summary of the issue
> (not repeating the standard's subclause heading)
> * "Subclause:" with numeric cross-reference to the main standard text
> * A concise summary of the issue in the style of a note
> (not wrong, but not necessarily exhaustive or normatively precise)
> * An example section (usual decorum)
>
> - Checklist items:
> * no duplication of normative requirements, i.e. verbs
> "shall", "may", "might", "could" are forbidden.
> "can" and "cannot" are ok.
> * Use "is incorrect" to characterize the offending behavior
> in the summary.
> * Monospace font for identifiers and keywords
> * Code comments aligned in columns.
> * Use "error" in code comments.
> * Sentence case for the title
>
>
> Next steps:
> - prepare DxxxxR0 paper, distributed to the ad-hoc group, which
> presents the above plus an intro paragraph for the future Annex.
> - After review and discussion, publish this as PxxxxR0 in a mailing.
> - Then, start appending actual entries to that paper.
> - Review and update incrementally.
> - Have CWG and then plenary approve the result, similar to any
> other paper.
> - Further updates can be through CWG issues, as needed.
>
> Technical hint: Make sure the paper is already using the standard's
> LaTeX infrastructure such that integration into the standard is
> easy on the editors.
>
> Thanks,
> Jens
> --
> SG23 mailing list
> SG23_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg23
>