This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Raw string support


On Thu, Apr 16, 2009 at 04:36:31PM +0000, Joseph S. Myers wrote:
> On Thu, 16 Apr 2009, Jakub Jelinek wrote:
> 
> > On Thu, Apr 16, 2009 at 02:47:50PM +0000, Joseph S. Myers wrote:
> > > Reading the specifications again, I see another issue.  Both C and C++ are 
> > > keeping the greedy algorithm for lexing, "the next preprocessing token is 
> > > the longest sequence of characters that could constitute a preprocessing 
> > > token".  So given
> > > 
> > > R" "
> > 
> > So do you suggest that we don't report any errors about
> > 1) characters not valid in d-char-sequence
> > 2) too long d-char-sequence
> > 3) unterminated raw string
> > and instead in all these cases break appart the prefix before initial "
> > as a separate token?  It is doable, but the user experience will be
> > terrible, finding out why it hasn't been lexed together as a preprocessing
> > token will be harder.
> 
> I suggest we wait to see what WG21 decides is the correct handling of 
> these cases.

Ok.  Has the C++
const char *p = R"@[abc]@";
const char *q = R"@@[abc]@@";
const char *r = R"@@@@@@@@[abc]@@@@@@@@";
validity been raised yet?  If phase 1 is supposed to replace all the
non-basic-source-charset chars with UCNs, then at least the wording
shouldn't talk about basic-source-charset characters or at least clarify, as
in that case other than basic-source-charset characters could never appear
at that point.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]