[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)

["joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>]

------- Additional Comments From joseph at codesourcery dot com  2004-12-16 12:33 -------
Subject: Re:  UCNs not recognized in identifiers
 (c++/c99)

On Thu, 16 Dec 2004, zack at codesourcery dot com wrote:

> Because of the ABI implications, I consider it completely unacceptable

Which ABI implications?

(a) It isn't explicitly stated that different UCNs designating the same 
character are equivalent to each other (and to that character) in 
identifiers, but I don't think there's any real doubt that they are meant 
to be equivalent.

(b) There is no normalisation, but I'm confident that the answer from WG14 
if this is queried would be that the standard is correct and by design it 
normatively references ISO 10646 (not Unicode) which doesn't include the 
normalisation definitions of UAX 15 and implementation of the standard is 
not meant to involve large external tables.  If there are cases of 
ambiguity a -Wnfc option (default on) to warn for identifiers not in NFC 
(or indeed -Wnfkc, default on, for identifiers not in NFKC) would draw 
users' attention to doubtful identifiers.  (TR 10176 expressly notes the 
problems of ambiguity of appearance of entirely different characters even 
without combining characters, says that language standards need not 
provide for normalisation if they allow combining characters, and excludes 
most combining characters where precombined characters are available for 
the specific purpose of avoiding alternate representations of 
identifiers.)

(c) Though we could do what we want with extended characters (as opposed 
to UCNs) in source files in phase 1, it seems safest to err on the side of 
rejecting all extended characters that wouldn't be accepted as UCNs, 
rather than e.g. applying NFC, to avoid giving identifiers with such 
characters a meaning which might then need to be preserved in future.

(d) There are genuine ABI issues with how extended characters are 
represented in object files, but I think those need to be resolved by 
selecting between UTF-8 and mangling (default UTF-8) based on target 
configurations rather than on the capabilities of the assembler and linker 
in use, and by getting an explicit statement about encoding put in the ELF 
specification.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449