On 28/04/2022 21.18, Jonathan Wakely wrote:
>
>
> On Thu, 28 Apr 2022 at 20:06, Jonathan Wakely <cxx_at_[hidden] <mailto:cxx_at_[hidden]>> wrote:
>
> On Thu, 28 Apr 2022 at 18:52, Jens Maurer wrote:
>
> On 28/04/2022 15.10, Jens Maurer via SG12 wrote:
> > On 28/04/2022 14.24, Jonathan Wakely via SG12 wrote:
> >> There were a number of NB comments for C++20 related to UB in the preprocessor:
> >> https://wiki.edg.com/bin/view/Wg21belfast/SG12 <https://wiki.edg.com/bin/view/Wg21belfast/SG12> <https://wiki.edg.com/bin/view/Wg21belfast/SG12 <https://wiki.edg.com/bin/view/Wg21belfast/SG12>>
> >> The response was to reject them, but create issues. Did the issues never get created?
> >
> > It doesn't seem so.
> >
> >> e.g. https://github.com/cplusplus/nbballot/issues/26 <https://github.com/cplusplus/nbballot/issues/26> <https://github.com/cplusplus/nbballot/issues/26 <https://github.com/cplusplus/nbballot/issues/26>> doesn't seem to have a corresponding CWG issue. Is there some other issues list I should be looking at, or did these get dropped on the floor?
> >
> > I think that action item got dropped on the floor.
> >
> > Working on it now.
>
> Shiny new core issues are now available:
>
> CWG2573 through CWG2581
>
> at https://cplusplus.github.io/CWG/issues/2573.html <https://cplusplus.github.io/CWG/issues/2573.html>
>
>
> Great, thanks!
>
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3801.pdf <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3801.pdf> has resolutions for some of them.
>
> I see some more UB in [cpp] which wasn't covered by those NB comments.
>
> [cpp.cond] p7 says "The identifiers __has_include and __has_cpp_attribute shall not appear in any context not mentioned in this subclause."
>
> IIUC failing to meet that requirement produces UB, even though it doesn't say the words "undefined behaviour".

That's not my reading. The core language uses "shall" for requirements
on user programs, the violation of which makes the program ill-formed.

> And similarly for p8, which says "Each preprocessing token that remains (in the list of preprocessing tokens that will become the controlling
> expression) after all macro replacements have occurred shall be in the lexical form of a token".
>
> Are these covered by any of the new issues?

They already say what we want them to say.

> The reason I started looking at this is that I was asked about this case:
>
> #if 0
> Can't be tokenized.
> #endif
>
> I think that's the subject of https://cplusplus.github.io/CWG/issues/2574.html <https://cplusplus.github.io/CWG/issues/2574.html> - is that right?

Yes. That one, and the related example without #if 0.

Jens