This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [4.1] UCNs in identifiers

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]