On Fri, Nov 10, 2023 at 10:38 AM Fraser Gordon via SG12
<sg12_at_[hidden]> wrote:
>
> Hi Jens,
>
> Is this intended to cover just the core language or would it also include the library wording?

This is intended only to cover core UB and IFNDR.

> 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
>
> _______________________________________________
> SG12 mailing list
> SG12_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg12
> Link to this post: http://lists.isocpp.org/sg12/2023/11/1021.php