On Sat, Apr 5, 2025 at 6:41 AM Herb Sutter via Core <core_at_[hidden]>
wrote:

> Thanks for the links!
>
>
>
> My question about markup style was not to change the direction of Shafik's
> annotation, but just to confirm what LaTeX markup you wanted us to generate
> (because in the original reply to the first time I asked that, Jens
> described more than one alternative), just so we can get started -- and if
> Shafik's is already doing that in the right direction then that's perfect
> and we can try to help/follow that. Furthermore, if EWG already approved
> this markup style, that's great and it sounds like it doesn’t need to go to
> EWG.
>
>
>
> *JF*, direction please re the annotation style to use to tag existing
> UB/IF-NDR (no new design proposals in this part of the work): Let us know
> if there’s anything you want EWG to see again. Otherwise we can assume that
> since this part has no design changes EWG doesn’t need to see it again,
> correct?
>

I'm sure EWG regulars will have opinions on the text that describes the UB.
They can bring these opinions about a non-normative annex to CWG or GitHub
pull requests :)


*CWG and Shafik*, direction please re just finding all the places to
> annotate: As we gear up to enlist more people to help gather the draft
> annotations (since there's a lot of UB to tag), would you prefer we do it
> in Shafik's branch? Perhaps as PRs? Shafik, is your branch up to date or do
> we need to keep it up to date? Just trying to determine where we want to
> collaborate together to start expanding the list.
>
>
>
> *CWG*, direction please re then actually reviewing batches of those
> proposed annotations as they get ready to be proposed for the IS draft:
> Procedurally, for just the annotations of existing UB/IF-NDR (excluding any
> future 'what to do about each case' changes which would be EWG papers), how
> does CWG want to see and review batches of annotation additions --
> presented as Core wording P papers? as opposed to, say, PRs (which, as was
> pointed out in EWG, have the drawback of not being available in all
> countries)?
>
>
>
> Thank you,
>
>
>
> Herb
>
>
>
>
>
> > -----Original Message-----
>
> > From: Jens Maurer <jens.maurer_at_[hidden]>
>
> > Sent: Friday, April 4, 2025 4:42 PM
>
> > To: Gabriel Dos Reis <gdr_at_[hidden]>; sg12_at_[hidden]; Herb
>
> > Sutter <herb.sutter_at_[hidden]>; 'Thomas Koeppe' <tkoeppe_at_[hidden]>;
>
> > core_at_[hidden]; 'WG21 Editors' <edit_at_[hidden]>
>
> > Cc: 'gasper.azman' <gasper.azman_at_[hidden]>
>
> > Subject: Re: [isocpp-sg12] [isocpp-core] UB and IFNDR Annex available in
> my
>
> > fork of the draft
>
> >
>
> >
>
> >
>
> > On 04/04/2025 20.27, Gabriel Dos Reis wrote:
>
> > > [Jens]
>
> > >
>
> > >> As I said, CWG has already approved Shafik's approach, in general.
>
> > >
>
> > >
>
> > >
>
> > > Shafik's work was reviewed multiple times
>
> > <https://github.com/cplusplus/papers/issues/473> by SG12 and EWG,
>
> > including this conversation and poll
>
> > <https://wiki.edg.com/bin/view/Wg21prague/D2118R0-EWG> in Prague.
>
> >
>
> > Thanks, and here is the follow-on paper
>
> >
>
> > https://github.com/cplusplus/papers/issues/1735
>
> >
>
> > reviewed by CWG in Spring 2024.
>
> >
>
> > > I am a bit confused by the suggestion of direction. Why?
>
> >
>
> > I don't know. Herb appears to continue to believe that EWG should chime
> in,
>
> > even though EWG approved Shafik's approach before (thanks for the
> pointer)
>
> > and knowing that having a curated list of (existing) UB as an Annex is
> not EWG
>
> > material.
>
> >
>
> > I wasn't advocating for a deviation from Shafik's approach, but Herb
> wanted
>
> > to know how an alternative might look like at the LaTeX level, so I
> replied.
>
> >
>
> > Jens
>
> >
>
> >
>
> > > -- Gaby
>
> > >
>
> > >
>
> > >
>
> > > -----Original Message-----
>
> > > From: SG12 <sg12-bounces_at_[hidden]> On Behalf Of Jens Maurer
>
> > > via SG12
>
> > > Sent: Friday, April 4, 2025 10:03 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: Jens Maurer <jens.maurer_at_[hidden]>; 'gasper.azman'
>
> > > <gasper.azman_at_[hidden]>
>
> > > Subject: Re: [isocpp-sg12] [isocpp-core] UB and IFNDR Annex available
>
> > > in my fork of the draft
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > > 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]
> <jens.maurer_at_[hidden]%20%3cmailto:jens.maurer_at_[hidden]>
>
> > <mailto:jens.maurer_at_[hidden]
> <jens.maurer_at_[hidden]%20%3cmailto:jens.maurer_at_[hidden]>>>
>
> > >
>
> > >>> Sent: Thursday, April 3, 2025 1:58 AM
>
> > >
>
> > >>> To: Herb Sutter <herb.sutter_at_[hidden]
> <herb.sutter_at_[hidden]%20%3cmailto:herb.sutter_at_[hidden]>
>
> > <mailto:herb.sutter_at_[hidden]
> <herb.sutter_at_[hidden]%20%3cmailto:herb.sutter_at_[hidden]>>>; 'Thomas
> Koeppe'
>
> > >
>
> > >>> <tkoeppe_at_[hidden] <mailto:tkoeppe_at_[hidden]>>;
>
> > core_at_[hidden] <mailto:core_at_[hidden]
> <core_at_[hidden]>>; 'WG21 Editors'
>
> > >
>
> > >>> <edit_at_[hidden] <mailto:edit_at_[hidden]>>;
>
> > >>> sg12_at_[hidden] <mailto:sg12_at_[hidden]
> <sg12_at_[hidden]>>
>
> > >
>
> > >>> Cc: 'Yaghmour, Shafik' <shafik.yaghmour_at_[hidden]
> <shafik.yaghmour_at_[hidden]%20%3cmailto:shafik.yaghmour_at_[hidden]>
>
> > <mailto:shafik.yaghmour_at_[hidden]
> <shafik.yaghmour_at_[hidden]%20%3cmailto:shafik.yaghmour_at_[hidden]>>>;
> 'gasper.azman'
>
> > >
>
> > >>> <gasper.azman_at_[hidden] <mailto: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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>
> > >>>>
>
> > eel.is%2Fc%2B%2Bdraft%2Fbasic.life%237.1&data=05%7C02%7Cgdr%40micro
>
> > >>>>
>
> > soft.com%7C80df61f962cb4776e78808dd739a9f49%7C72f988bf86f141af91ab
>
> > 2
>
> > >>>>
>
> > d7cd011db47%7C1%7C0%7C638793830145046933%7CUnknown%7CTWFpbG
>
> > Zsb3d8ey
>
> > >>>>
>
> > JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT
>
> > >>>>
>
> > WFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UCSFELj5ZU1823tB7E9j
>
> > UGmK
>
> > >>>> RTeFV13hmViVlJBHRTg%3D&reserved=0
>
> > >>>> <https://eel.is/c++draft/basic.life#7.1>> — the pointer is used
>
> > >
>
> > >>>> as the operand of a /delete-expression/
>
> > >
>
> > >>>>
>
> > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>
> > >>>> eel.is%2Fc%2B%2Bdraft%2Fexpr.delete%23nt%3Adelete-
>
> > expression&data=0
>
> > >>>>
>
> > 5%7C02%7Cgdr%40microsoft.com%7C80df61f962cb4776e78808dd739a9f49
>
> > %7C7
>
> > >>>>
>
> > 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638793830145069690%7C
>
> > Unkn
>
> > >>>>
>
> > own%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI
>
> > sIlAiO
>
> > >>>>
>
> > iJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=X
>
> > 1%2
>
> > >>>> FMB9VuAcCxU753oY1PRG0LEH9KGwJFtrXZu7xvc9s%3D&reserved=0
>
> > >>>> <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
>
> > >
>
> > >>
>
> > >
>
> > >
>
> > >
>
> > > _______________________________________________
>
> > >
>
> > > SG12 mailing list
>
> > >
>
> > > SG12_at_[hidden] <mailto:SG12_at_[hidden]
> <SG12_at_[hidden]>>
>
> > >
>
> > > Subscription:
>
> > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
>
> > >
>
> > s.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg12&data=05%7C02%7Cgdr%40m
>
> > icr
>
> > >
>
> > osoft.com%7C80df61f962cb4776e78808dd739a9f49%7C72f988bf86f141af91a
>
> > b2d7
>
> > >
>
> > cd011db47%7C1%7C0%7C638793830145081207%7CUnknown%7CTWFpbGZs
>
> > b3d8eyJFbXB
>
> > >
>
> > 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp
>
> > bCIsI
>
> > >
>
> > ldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UEIfhsYcHYuwvbrKe93f8TplHGrq
>
> > W2W85hb
>
> > > 5YXie3p8%3D&reserved=0
>
> > > <https://lists.isocpp.org/mailman/listinfo.cgi/sg12>
>
> > >
>
> > > Link to this post:
>
> > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists
>
> > >
>
> > .isocpp.org%2Fsg12%2F2025%2F04%2F1034.php&data=05%7C02%7Cgdr%40
>
> > microso
>
> > >
>
> > ft.com%7C80df61f962cb4776e78808dd739a9f49%7C72f988bf86f141af91ab2
>
> > d7cd0
>
> > >
>
> > 11db47%7C1%7C0%7C638793830145094521%7CUnknown%7CTWFpbGZsb3d
>
> > 8eyJFbXB0eU
>
> > >
>
> > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI
>
> > ldU
>
> > >
>
> > IjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=tmgkY2Hgn2B37dehMW%2FSe7CSN
>
> > Kk%2BfAnxNu
>
> > > qHiGPubYM%3D&reserved=0
>
> > > <http://lists.isocpp.org/sg12/2025/04/1034.php>
>
> > >
>
>
> _______________________________________________
> Core mailing list
> Core_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core
> Link to this post: http://lists.isocpp.org/core/2025/04/17823.php
>