public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Joseph S. Myers" <joseph@codesourcery.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Tom Tromey <tromey@redhat.com>, Jason Merrill <jason@redhat.com>,
	     gcc-patches@gcc.gnu.org,
	Kris Van Hees <kris.van.hees@oracle.com>,
	     Ulrich Drepper <drepper@redhat.com>
Subject: Re: [PATCH] Support for C++0x and C1x u8 string literals and raw  string literals
Date: Fri, 12 Sep 2008 16:52:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.64.0809121541540.17535@digraph.polyomino.org.uk> (raw)
In-Reply-To: <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

  reply	other threads:[~2008-09-12 15:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-12 14:22 Jakub Jelinek
2008-09-12 16:52 ` Joseph S. Myers [this message]
2008-09-12 19:40   ` Jakub Jelinek
2008-09-12 20:16     ` Joseph S. Myers
2008-09-12 21:00       ` Jakub Jelinek
2008-09-12 21:04         ` Joseph S. Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0809121541540.17535@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=drepper@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=jason@redhat.com \
    --cc=kris.van.hees@oracle.com \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).