On Fri, 16 Sep 2005, Geoffrey Keating wrote:
> > Adding salt to the wound, of course, is that for C the only difference
> > between an (A) or (B) and a (C) implementation is that a (C)
> > implementation is less expressive: there are some programs, all of
> > which are erroneous and require a diagnostic, that can't be written.
> > So you lose compiler performance just so users have another bullet
> > to shoot their feet with.
On Fri, Sep 16, 2005 at 12:12:34PM +0000, Joseph S. Myers wrote:
> C++ requires (A) and provides examples of valid programs where it can be
> told whether a normalisation of UCNs is part of the implementation-defined
> phase 1 transformation. As I gave in a previous discussion,
>
> #include <stdlib.h>
> #include <string.h>
> #define h(s) #s
> #define str(s) h(s)
> int
> main()
> {
> if (strcmp(str(str(\u00c1)), "\"\\u00c1\"")) abort ();
> if (strcmp(str(str(\u00C1)), "\"\\u00C1\"")) abort ();
> }
OK, Joseph, you've given us a valid program where normalization of UCNs
makes a difference.
But the question on my mind is, is it worth the effort to get this right?
Rigorous standards compliance is a good target to aim for. But if there
is a cost in compiler performance, every user has to pay, for every
program, just so that weird cases like the one you describe come out
correctly.
To me, even a 1% performance hit to fix this would be excessive. We're
in a constant losing battle to keep each gcc release from being slower
than the last one; sometimes we gain a bit of ground but more often we
lose ground.
