aaron.ballman added a comment. In D106577#2906542 <https://reviews.llvm.org/D106577#2906542>, @rsmith wrote:
> If Aaron's checked with WG14 and the intent is for this to only constrain how > literals are represented, and not the complete implementation, then I'm > entirely fine with us defining the macro ourselves. But that's not the > interpretation that several other vendors have taken. If we're confident that > the intent is just that this macro lists (effectively) the latest version of > the Unicode standard that we've heard of, we should let the various libc > vendors that currently define the macro know that they're doing it wrong and > the definition belongs in the compiler. The discussion on the WG14 reflectors has wound down. Summarizing the key point of the discussion, Richard asked: > One specific example I'd like to be considered: > Suppose the C standard library implementation's mbstowcs converts a certain > multi-byte character C to somewhere in the Unicode private use area, because > Unicode version N doesn't have a corresponding character. Suppose further > that the compiler is aware of Unicode version N+1, in which a character > corresponding to C was added. Is an implementation formed by that combination > of compiler and standard library, that defines `__STDC_ISO_10646__` to N+1, > conforming? Or is it non-conforming because it represents character C as > something other than the corresponding short name from Unicode version N+1? And David Keaton (long-time WG14 member and current convener) replied: > Yikes! It does indeed sound like the library would affect the value of > `__STDC_ISO_10646__` in that case. Thanks for clarifying the details. There was no further discussion after that point, so I think the unofficial WG14 stance is that the compiler and the library need to collude on setting the value of that macro. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D106577/new/ https://reviews.llvm.org/D106577 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
