Date: Fri, 4 Apr 2025 17:41:35 -0400
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?
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> 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> 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> 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 < <mailto:sg12-bounces_at_[hidden]> sg12-bounces_at_[hidden]> On Behalf Of Jens Maurer
> > via SG12
> > Sent: Friday, April 4, 2025 10:03 AM
> > To: Herb Sutter < <mailto:herb.sutter_at_[hidden]> herb.sutter_at_[hidden]>; 'Thomas Koeppe'
> > < <mailto:tkoeppe_at_[hidden]> tkoeppe_at_[hidden]>; <mailto:core_at_[hidden]> core_at_[hidden]; 'WG21 Editors'
> > < <mailto:edit_at_[hidden]> edit_at_[hidden]>; <mailto:sg12_at_[hidden]> sg12_at_[hidden]
> > Cc: Jens Maurer < <mailto:jens.maurer_at_[hidden]> jens.maurer_at_[hidden]>; 'gasper.azman'
> > < <mailto:gasper.azman_at_[hidden]> 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 < <mailto:jens.maurer_at_[hidden]%20%3cmailto:jens.maurer_at_[hidden]> jens.maurer_at_[hidden]
<mailto:jens.maurer_at_[hidden]%20%3cmailto:jens.maurer_at_[hidden]> > <mailto:jens.maurer_at_[hidden]>>
> >
> >>> Sent: Thursday, April 3, 2025 1:58 AM
> >
> >>> To: Herb Sutter < <mailto:herb.sutter_at_[hidden]%20%3cmailto:herb.sutter_at_[hidden]> herb.sutter_at_[hidden]
<mailto:herb.sutter_at_[hidden]%20%3cmailto:herb.sutter_at_[hidden]> > <mailto:herb.sutter_at_[hidden]>>; 'Thomas Koeppe'
> >
> >>> < <mailto:tkoeppe_at_[hidden]%20%3cmailto:tkoeppe_at_[hidden]> tkoeppe_at_[hidden] <mailto:tkoeppe_at_[hidden]>>;
> <mailto:core_at_[hidden]> core_at_[hidden] < <mailto:core_at_[hidden]> mailto:core_at_[hidden]>; 'WG21 Editors'
> >
> >>> < <mailto:edit_at_[hidden]%20%3cmailto:edit_at_[hidden]> edit_at_[hidden] <mailto:edit_at_[hidden]>>;
> >>> <mailto:sg12_at_[hidden]> sg12_at_[hidden] < <mailto:sg12_at_[hidden]> mailto:sg12_at_[hidden]>
> >
> >>> Cc: 'Yaghmour, Shafik' < <mailto:shafik.yaghmour_at_[hidden]%20%3cmailto:shafik.yaghmour_at_[hidden]> shafik.yaghmour_at_[hidden]
<mailto:shafik.yaghmour_at_[hidden]%20%3cmailto:shafik.yaghmour_at_[hidden]> > <mailto:shafik.yaghmour_at_[hidden]>>; 'gasper.azman'
> >
> >>> < <mailto:gasper.azman_at_[hidden]%20%3cmailto:gasper.azman_at_[hidden]> 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> 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> 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
> >
> > <mailto:SG12_at_[hidden]> SG12_at_[hidden] < <mailto:SG12_at_[hidden]> mailto:SG12_at_[hidden]>
> >
> > Subscription:
> > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist> 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> https://lists.isocpp.org/mailman/listinfo.cgi/sg12>
> >
> > Link to this post:
> > <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists> 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> http://lists.isocpp.org/sg12/2025/04/1034.php>
> >
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?
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> 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> 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> 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 < <mailto:sg12-bounces_at_[hidden]> sg12-bounces_at_[hidden]> On Behalf Of Jens Maurer
> > via SG12
> > Sent: Friday, April 4, 2025 10:03 AM
> > To: Herb Sutter < <mailto:herb.sutter_at_[hidden]> herb.sutter_at_[hidden]>; 'Thomas Koeppe'
> > < <mailto:tkoeppe_at_[hidden]> tkoeppe_at_[hidden]>; <mailto:core_at_[hidden]> core_at_[hidden]; 'WG21 Editors'
> > < <mailto:edit_at_[hidden]> edit_at_[hidden]>; <mailto:sg12_at_[hidden]> sg12_at_[hidden]
> > Cc: Jens Maurer < <mailto:jens.maurer_at_[hidden]> jens.maurer_at_[hidden]>; 'gasper.azman'
> > < <mailto:gasper.azman_at_[hidden]> 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 < <mailto:jens.maurer_at_[hidden]%20%3cmailto:jens.maurer_at_[hidden]> jens.maurer_at_[hidden]
<mailto:jens.maurer_at_[hidden]%20%3cmailto:jens.maurer_at_[hidden]> > <mailto:jens.maurer_at_[hidden]>>
> >
> >>> Sent: Thursday, April 3, 2025 1:58 AM
> >
> >>> To: Herb Sutter < <mailto:herb.sutter_at_[hidden]%20%3cmailto:herb.sutter_at_[hidden]> herb.sutter_at_[hidden]
<mailto:herb.sutter_at_[hidden]%20%3cmailto:herb.sutter_at_[hidden]> > <mailto:herb.sutter_at_[hidden]>>; 'Thomas Koeppe'
> >
> >>> < <mailto:tkoeppe_at_[hidden]%20%3cmailto:tkoeppe_at_[hidden]> tkoeppe_at_[hidden] <mailto:tkoeppe_at_[hidden]>>;
> <mailto:core_at_[hidden]> core_at_[hidden] < <mailto:core_at_[hidden]> mailto:core_at_[hidden]>; 'WG21 Editors'
> >
> >>> < <mailto:edit_at_[hidden]%20%3cmailto:edit_at_[hidden]> edit_at_[hidden] <mailto:edit_at_[hidden]>>;
> >>> <mailto:sg12_at_[hidden]> sg12_at_[hidden] < <mailto:sg12_at_[hidden]> mailto:sg12_at_[hidden]>
> >
> >>> Cc: 'Yaghmour, Shafik' < <mailto:shafik.yaghmour_at_[hidden]%20%3cmailto:shafik.yaghmour_at_[hidden]> shafik.yaghmour_at_[hidden]
<mailto:shafik.yaghmour_at_[hidden]%20%3cmailto:shafik.yaghmour_at_[hidden]> > <mailto:shafik.yaghmour_at_[hidden]>>; 'gasper.azman'
> >
> >>> < <mailto:gasper.azman_at_[hidden]%20%3cmailto:gasper.azman_at_[hidden]> 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> 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> 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
> >
> > <mailto:SG12_at_[hidden]> SG12_at_[hidden] < <mailto:SG12_at_[hidden]> mailto:SG12_at_[hidden]>
> >
> > Subscription:
> > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist> 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> https://lists.isocpp.org/mailman/listinfo.cgi/sg12>
> >
> > Link to this post:
> > <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists> 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> http://lists.isocpp.org/sg12/2025/04/1034.php>
> >
Received on 2025-04-04 21:41:52