On 04/04/2025 09.58, Herb Sutter wrote:
> Thanks Jens,
>
>> An alternative approach would be the one employed for the "Index of
>> implementation-defined behavior"
>> where we add a short phrase into the main body LaTeX source proper and the
>> index is generated automatically.
>> However, this approach does not work well on the LaTeX source maintenance
>> level if we want to add examples and more elaborate explanation: those
>> additional large-ish chunks of text should be maintained in the LaTeX source
>> for the Annex, not inline with the main body.
>
> Is there a specific approach you think might be good, and what would the LaTeX diff look like for that for this particular example? I'm just looking for some initial guidance, and the group of course still needs to weigh in (esp. CWG).

As I said, CWG has already approved Shafik's approach, in general.

Example for the "alternative":

\pnum
\indextext{expression!unary operator}%
\indextext{operator!unary}%
The unary \tcode{*} operator performs \defn{indirection}.
\indextext{dereferencing|see{indirection}}%
Its operand shall be a prvalue of type ``pointer to \tcode{T}'',
where \tcode{T} is an object or function type.
The operator yields an lvalue of type \tcode{T}.
If the operand points to an object or function,
the result denotes that object or function;
otherwise, the behavior is <del>undefined</del>
>>>> HERE >>>> <ins>\ub{indirection through a past-the-end, null, or invalid pointer value}</ins>
except as specified in \ref{expr.typeid}.
\begin{note}
\indextext{type!incomplete}%
Indirection through a pointer to an incomplete type (other than
\cv{} \keyword{void}) is valid. The lvalue thus obtained can be
used in limited ways (to initialize a reference, for example); this
lvalue must not be converted to a prvalue, see~\ref{conv.lval}.
\end{note}


(I don't think this is a good idea, because it prevents us from
having examples and a bit more narrative.)

> For the tags themselves, I agree they're editorial. But for just the first batch, I thought it would be useful to let EWG see that to make sure everyone's aware of the process we're using for documenting what we already have. And I think all of the new tags should still be reviewed by CWG before merging because I think CWG needs to agree the tags we're adding are descriptively correct, even if they are technically editorial. Does that make sense?

It is understood that CWG will need to review additions of large chunks of
text to the standard document, even if in an informative Annex and deemed
editorial.

Jens



> Herb
>
>
>
>> -----Original Message-----
>> From: Jens Maurer <jens.maurer_at_[hidden]>
>> Sent: Thursday, April 3, 2025 1:58 AM
>> To: Herb Sutter <herb.sutter_at_[hidden]>; 'Thomas Koeppe'
>> <tkoeppe_at_[hidden]>; core_at_[hidden]; 'WG21 Editors'
>> <edit_at_[hidden]>; sg12_at_[hidden]
>> Cc: 'Yaghmour, Shafik' <shafik.yaghmour_at_[hidden]>; 'gasper.azman'
>> <gasper.azman_at_[hidden]>
>> Subject: Re: [isocpp-core] UB and IFNDR Annex available in my fork of the
>> draft
>>
>>
>>
>> On 02/04/2025 23.57, Herb Sutter wrote:
>>> Shafik’s fork below adds tags such as \ifndriref{tag} and \ubiref{tag}, for
>> example:
>>>
>>> - no diagnostic required.
>>> + no diagnostic required\ifndriref{basic.def.odr.exact.one.def}.
>>>
>>> - program has undefined behavior if
>>> + program has undefined behavior\ubiref{lifetime.outside.pointer} if
>>>
>>> These are considered editorial and can be added while still working on
>> C++26.
>>>
>>> The Appendix notes that after the EWG telecon I got strong
>> feedback/suggestions (but that was NOT yet presented and approved by
>> EWG) that the tag should include the specific phrase that introduces the
>> UB/IF-NDR (if explicit), and a short description of how it arises?
>>
>> "if explicit" can go. All UB/IF-NDR should be explicit; if some particular
>> instance isn't, it needs to be a core issue to add the explicitness.
>>
>>> *Jens and Thomas (and everyone)*, what do you suggest that the LaTeX
>> spelling and format for that UB/IF-NDR tag to be? And should it include a
>> description of the UB/IF-NDR?
>>
>> There are different meanings of "tag" that we're considering here, and it helps
>> to clearly differentiate those.
>>
>> The LaTeX markup that Shafik's patch adds creates a cross-reference to the
>> Annex section in the main body of the text, plus creates verbose-ish Annex
>> entries.
>> That's clearly editorial; if (for some transition period) we don't want the
>> Annex (yet), we could add the main-body LaTeX tags without any change to
>> the textual contents of the rendered PDF.
>>
>> The Annex itself is clearly descriptive (quotes and examples) and thus is not
>> normative, either. At the time Shafik's approach was discussed in CWG, CWG
>> was tentatively-happy with it. Now, this appears to be considered an EWG
>> matter (why?), so are they ok with that style, or do they want something else?
>>
>> An alternative approach would be the one employed for the "Index of
>> implementation-defined behavior"
>> where we add a short phrase into the main body LaTeX source proper and the
>> index is generated automatically.
>> However, this approach does not work well on the LaTeX source maintenance
>> level if we want to add examples and more elaborate explanation: those
>> additional large-ish chunks of text should be maintained in the LaTeX source
>> for the Annex, not inline with the main body.
>>
>>> Example: Please show how you would like to tag [basic.life]/7, which says in
>> part:
>>>
>>>
>>>
>>> […] The program has undefined behavior if
>>>
>>> (7.1) <https://eel.is/c++draft/basic.life#7.1> — the pointer is used
>>> as the operand of a /delete-expression/
>>> <https://eel.is/c++draft/expr.delete#nt:delete-expression>,
>>>
>>> […]
>>>
>>> Shafik has added this edit:
>>>
>>> - program has undefined behavior if
>>> + program has undefined behavior\ubiref{lifetime.outside.pointer} if
>>>
>>>
>>>
>>> What should this example look like in LaTeX?
>>>
>>>
>>> Goal: To get enough unofficial direction here to write a paper proposing the
>> diff for a initial small set of cases (perhaps a subset of Shafik’s, thanks Shafik!)
>> for EWG to review, and if approved send to CWG for review, just to set out a
>> precedent that we can then follow as we ramp up doing this systematically.
>>
>> There is nothing for EWG to review here, because there is no language change
>> being proposed here. (Unlike when we get to the point how to address
>> particular instances of undefined behavior.)
>>
>> Thanks,
>> Jens
>