C++ Logo


Advanced search

Re: [SG16] Handling literals throughout the translation phases

From: Hubert Tong <hubert.reinterpretcast_at_[hidden]>
Date: Thu, 17 Dec 2020 20:51:12 -0500
On Thu, Dec 17, 2020 at 4:33 PM Jens Maurer via SG16 <sg16_at_[hidden]>

> I'm working on a paper that switches C++ to a modified "model B" approach
> for
> universal-character-names as described in the C99 Rationale v5.10, section
> 5.2.1.
> There are some facts that are hard to reconcile in a nice model:
> - Concatenation of string-literals might change the meaning of
> numeric-escape-sequences, e.g. "\x5" "e" should not become "\x5e".
> - In general, string-literals contain (Unicode) characters, but
> a numeric-escape-sequences embodies a code unit (not a character).
> - We can't translate some escape-sequences earlier and some
> escape-sequences later, because "\\x5e" might turn into the
> code unit 0x5e that way, but the four characters \x5e were
> actually intended.
> - Not all string-literals should be transcoded to execution (literal)
> encoding. For example, the argument to static_assert should not be
> so treated.
I guess this is also the case for strings meant for compiler extensions
(like extended asm syntax).

> My current idea is to focus on the creation of the string literal
> object; that's when transcoding to execution (literal) encoding
> happens. All other uses of string-literals don't produce objects,
> so aren't transcoded.
I'm not sure there's a real use of a string literal object here:
extern "\x43" "++" {}

but various compilers accept the code.

> In order to be able to interpret escape-sequences in phase 5/6,
> we need a "tunnel" for numeric-escape-sequences. One idea would
> be to add "code unit characters" to the translation character set,
> where each such character represents a code unit coming from a
> numeric-escape-sequence. The sole purpose is to keep the
> code units safe until we produce the initializer for the
> string literal object.
> The alternative would be to delay all interpretation of escape-
> sequences to when we produce the initializer for the string
> literal object, but that also means we need to delay string
> literal concatenation until that time (see first item above).
Delaying string literal concatenation introduces knock-on effects:
int operator "" "" _hello(const char *);

So, keeping code units safe until we need to know the contents of the
string for some reason or another sounds like a good direction.

> Ideas? Opinions?
> Jens
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16

Received on 2020-12-17 19:51:31