C++ Logo

sg16

Advanced search

Re: [SG16] SG16 meeting summary for March 24th, 2021

From: Corentin Jabot <corentinjabot_at_[hidden]>
Date: Sun, 28 Mar 2021 23:13:42 +0200
On Sun, Mar 28, 2021 at 11:01 PM Jens Maurer <Jens.Maurer_at_[hidden]> wrote:

> On 28/03/2021 22.56, Alisdair Meredith wrote:
> > Thanks - that was exactly my thoughts, and I missed it when Corentin
> tried to correct me. All clear now, although is the reference to Raw
> string literals still useful, or more likely to lead to folks like me mid
> reading too quickly, and getting confused?
> >
> > I believe there would be no cha he of behavior if we strike the “except”
> that can no longer occur.
>
> No. If we strike the "except", we give the impression that a spliced
> character
> sequence in a raw string literal that looks like a UCN is somehow special,
> and would cause undefined behavior. It doesn't.
>

We should strike
> if a splice results in a character sequence that matches the syntax of a
*universal-character-name*
<http://eel.is/c++draft/lex#nt:universal-character-name>, the behavior is
undefined.
Both because it matches existing practices (except msvc) and because it
follows the flow of the wording. (ucn are replaced in the next phase)

What should happen when a ucn is formed by a preprocessor in phase 4 is
less clear to me.
Given that no compiler do the right thing, it would be sensible that it
would be ill-formed https://godbolt.org/z/of4W9dG8h

> If a ' or a " character matches the last category, the behavior is
undefined
That should be ill-formed, which is what all compilers do. I suspect this
specific undefined behavior is an artifact of C wording



>
> (Note that it says "that matches the syntax". Although UCNs are never
> formed in raw string literals, the phrasing could be read to actually
> care for UCNs in raw string literals. Not good.)
>
> Jens
>
>
>

Received on 2021-03-28 16:13:58