This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Support for C++0x and C1x u8 string literals and raw string literals
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, Jason Merrill <jason at redhat dot com>, gcc-patches at gcc dot gnu dot org, Kris Van Hees <kris dot van dot hees at oracle dot com>, Ulrich Drepper <drepper at redhat dot com>
- Date: Fri, 12 Sep 2008 15:56:38 +0000 (UTC)
- Subject: Re: [PATCH] Support for C++0x and C1x u8 string literals and raw string literals
- References: <20080912132007.GA9666@hs20-bc2-1.build.redhat.com>
On Fri, 12 Sep 2008, Jakub Jelinek wrote:
> The following patch adds support for the rest. There is one thing
> in which currently gcc raw strings violates the standard, because of the
> controversial extension which treats backslash whitespace newline
> the same as backslash newline. I've added test for that and xfailed
> it for now. For the raw string delimiter sequences I've tried to
That is not a standard violation - it's GCC defining a phase 1 translation
that cannot result in all possible sequences of basic source characters.
(I do think however we should stop doing this, and so allow backslash
whitespace newline sequences to be represented.)
> be really pedantic and accept only basic source charset character except
> the listed 7, rather than say all characters except the listed 7
> plus maybe disallowing '\0', as this is a new feature I think being
> pedantic doesn't hurt. In one of the raw string papers floating
> around there was an example using R"@[...]@" which is not pedantically
> valid, as @ is not basic source charset character. u8 string
But that example is conditionally valid in C++ only, although not in C,
because in phase 1 @ will have been converted to a UCN (part of the
existing C++98 semantics we don't implement). The validity is only
conditional because there is no requirement to use the same UCN for each
instance of @.
I'll raise the issue on the WG14 reflector. I've raised another question
I noticed there - N1333 would change string literals for C to be
const-qualified, which it seems to be agreed was not intended.
As this is obviously a new feature for 4.5, by the time Stage 1 starts we
may well have new C and C++ drafts with some of the glitches sorted out.
--
Joseph S. Myers
joseph@codesourcery.com