On Thu, 26 Sep 2019, Eric Botcazou wrote: > > For C, I think such UCNs violate the Semantics but not the Constraints on > > UCNs, so no diagnostic is actually required in C, although it is permitted > > as a pedwarn / error. > > > > However, while C++ doesn't have that Semantics / Constraints division, > > it's also the case that before C++2a, C++ only has a dated normative > > reference to ISO/IEC 10646-1:1993 (C++2a adds an undated reference and > > says the dated one is only for deprecated features, as well as explicitly > > making such UCNs outside the ISO 10646 code point range ill-formed). So I > > think that for C++, this is only correct as an error / pedwarn in the > > C++2a case. > > OK, thanks for the exegesis. ;-) Revision version attached.
Checking "CPP_OPTION (pfile, lang) == CLK_CXX2A" is problematic because future versions later than C++2a should be handled the same as C++2a. The only place I see doing something similar (outside of init.c, most version conditionals are handled via language flags set there) does "CPP_OPTION (pfile, lang) > CLK_CXX11" (for "In C++14 and up these suffixes are in the standard library, so treat them as user-defined literals.", two places doing the same comparison). So I think that "CPP_OPTION (pfile, lang) > CLK_CXX17" is the right thing to replace the comparisons against CLK_CXX2A and CLK_GNUCXX2A. The patch is OK with that change. -- Joseph S. Myers jos...@codesourcery.com
