From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13138 invoked by alias); 14 Mar 2008 00:56:35 -0000 Received: (qmail 13115 invoked by uid 22791); 14 Mar 2008 00:56:24 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 14 Mar 2008 00:56:01 +0000 Received: (qmail 18907 invoked from network); 14 Mar 2008 00:55:59 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Mar 2008 00:55:59 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.68) (envelope-from ) id 1JZyDG-0003Q1-Eg; Fri, 14 Mar 2008 00:55:58 +0000 Date: Fri, 14 Mar 2008 01:14:00 -0000 From: "Joseph S. Myers" To: Kris Van Hees cc: Andrew Pinski , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] utf-16 and utf-32 support in C and C++ In-Reply-To: <20080313201946.GG19427@oracle.com> Message-ID: References: <20080313193208.GE19427@oracle.com> <20080313195854.GF19427@oracle.com> <20080313201946.GG19427@oracle.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2008-03/txt/msg00857.txt.bz2 On Thu, 13 Mar 2008, Kris Van Hees wrote: > Here you go. Sorry about that. > > Index: gcc/testsuite/gcc.dg/utf32-2.c > =================================================================== > --- gcc/testsuite/gcc.dg/utf32-2.c (revision 0) > +++ gcc/testsuite/gcc.dg/utf32-2.c (revision 0) > @@ -0,0 +1,30 @@ > +/* Contributed by Kris Van Hees */ > +/* Test the support for char32_t* string constants. */ > +/* { dg-do run } */ > +/* { dg-options "-std=c99 -Wall -Werror" } */ A TR Type 2 is neither a standard nor an amendment to a standard (the same also applies to Type 1 and Type 3 TRs, but this is a Type 2 TR). Thus, the new syntax *must not* be accepted in C99 or C90 or C++98 mode, and there must be testcases to verify that it is not accepted in those modes. It must only be accepted in gnu89 / gnu99 / ... extension modes, or in c++0x mode (or with a special option to enable support for the new syntax in older standard modes if absolutely necessary). In the modes for existing C and C++ standards, U or u must be lexed as separate tokens from a following string (they could be macros, so valid code could have its semantics affected; the testcases should probably involve u and U as macros). -- Joseph S. Myers joseph@codesourcery.com