Ross Ridge wrote: > >Well, maybe I'm missing something, but it never converts input characters > >to UCNs so that means it doesn't do (A) or (B), and the only thing it > >converts to wide characters are wide string literals, so it doesn't do > >(C).
On Thu, Sep 15, 2005 at 07:24:47AM -0400, Robert Dewar wrote: > You are thinking operationally, when you should think semantically. > Remember that as-if applies here. The rules as stated give ways to > achieve certain effects, the question is not whether we are following > the operational rules, but whether we are following the effects. This was exactly my point when I asked for an example. Joseph Myers pointed to some, in the discussion for PR 9449 (particularly comment #39). The examples, however, are obscure enough that users might prefer having a few corner-case bugs to a rigorously correct, but slower, implementation. For example, if the cost of correctly handling #define foo \u00b1 #define foo \u00B1 /* invalid: different spelling in replacement */ #define \u00c1 foo #define \u00C1 foo /* valid: spelling of macro *name* can vary */ is a 10% slowdown in preprocessor speed, I'd rather leave it broken and document the breakage. On the other hand, if a correct implementation of these rules does not impose a speed penalty, wonderful. It is truly annoying that the C and C++ committees created different rules, BTW.
