Re: [4.1] UCNs in identifiers

[Geoffrey Keating <geoffk at apple dot com>]

On 06/01/2005, at 9:59 PM, Zack Weinberg wrote:

> You may not commit this patch, or any other patch along the same
> lines.  This feature MUST NOT be implemented until the associated bugs
> in the C and C++ standards are fixed.  I mean to rip out the bits of
> support that are already there.
>
> Apple may of course do whatever it likes with its own branch, but you
> should be aware that you are setting yourself up for major problems
> with shared library ABIs.
>
> See PR 9449 for gory details (in particular comment #4).

I disagree, for three reasons:

1. GCC's stated goal is to be standards-conformant.  The standard is 
quite clear.  The fact that you do not like the consequences of what 
the standard says is unfortunate, and I do encourage you to get the 
standards fixed in the very obscure case of certain Hebrew characters, 
but that's insufficient reason to not implement the standard.  We 
implement the standard in cases even where the feature is completely 
objectionable, like trigraphs, and this is not nearly that bad.

2. I believe that the standards will never be "fixed" in the way you 
wish.  The standards intentionally excluded combining forms in order to 
prevent the problem you are describing.

3. You have not considered what could be done even if the worst-case 
scenario (which I don't think will ever happen) of a shared library, 
widely distributed, with an ABI that contains a UCN, and that UCN 
becomes prohibited in a later version of the standard.  There are 
obvious solutions to fix this extremely unlikely case, most notably use 
of an asm() modifier on the declaration.

Attachment: smime.p7s
Description: S/MIME cryptographic signature