From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9442 invoked by alias); 18 Jan 2014 23:33:29 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 9416 invoked by uid 48); 18 Jan 2014 23:33:26 -0000 From: "wjl at icecavern dot net" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/59873] The value of char32_t U'\u0000' and char16_t u'\u000' is 1, instead of 0. Date: Sat, 18 Jan 2014 23:33:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: major X-Bugzilla-Who: wjl at icecavern dot net X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-01/txt/msg02008.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873 --- Comment #5 from Wesley J. Landaker --- (In reply to Marc Glisse from comment #4) > Seems to be on purpose, see the comment before _cpp_valid_ucn in > libcpp/charset.c, and the last instruction in that function. > > [lex.charset] is a bit hard to read for me. If I'm reading that comment right, it sounds like the C++11 standard says that something like: U'\u0000' should yield a compiler error, like it currently does with U'\ud800' (a surrogate), instead of silently working in an unexpected manner. Assuming this line of reasoning is correct, my second test program (the char32_literal_test.c++) shows that gcc has a bug in that it does not propertly *reject* any invalid \uXXXX or \UXXXXXXXX except for surrogates. (As an aside, if this really does violate the C++11 standard, clang has this same bug -- it just behaved in the way I naively expected it to.)