From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Subject: Re: Questions about token merging and trigraphs
Organization: University of Helsinki
Date: Fri, 18 Dec 1992 20:54:05 GMT

mcdonald@aries.scs.uiuc.edu (J. D. McDonald) writes:
>Trigraphs were by far the most serious mistake made by the ANSI C
>committee, as serious, in fact, as the myriads of stupid things done by the
>Fortran committee.
>
>\LARGE
>
>THEY BREAK EXISTING CODE!!!
>
>\normal
>
>and that alone shoudl have said that they **SHOULD NOT HAVE BEEN INCLUDED**.

I assume that you are also of the opinion that everything else that
breaks existing code should have been left out of the standard?  In
that case, we would only have a very, very weak standard, that more or
less only standardized a (large) subset of K&R-1 (not all of it, since
not all existing code followed K&R-1).

Let's face it: In order to create the standard, the committee had to
make a lot of tough decisions, some of which broke things that
previously worked.  However, with few exceptions things that worked
(portably) in K&R C, still work unchanged.  Trigraphs are one of the
exceptions, new keywords, withdrawn support for long floats, the usual
arithmetic conversions, and structure member name spaces are others.
Most of the other things that broke were things that didn't work
universally even before the standard.

As far as I know, all or at least most of the dangerous changes are
discussed in the Rationale, which used to accompany the standard (this
was changed, unfortunately, when ISO adopted the standard).  I do know
that it points out that programs containing the trigraph sequences may
produce different results: I have the Rationale beside me as I write
this.  (I don't have the standard itself, so I can't check whether the
standard itself points out these things as well.)

What I don't understand is why so many people are so vehemently
opposed to trigraphs.  If you compile a K&R C program under Standard
C, you'll have to check for a lot of small details anyway, and
trigraphs is one of the smallest and probably the easiest one to
automate (a program to check for trigraphs can be written in a few
minutes).  If you write new code, you need at most be aware of the
fact that trigraphs exist and avoid writing them by mistake.

I can't see a better solution than trigraphs (I'm not claiming that
trigraphs are a good solution, only that it is a good enough
solution), especially considering the constraint that only characters
that are guaranteed to be portable between different machines (if you
want to start introducing new characters to the set of characters that
C requires, you are only enlarging the problem).

But perhaps it is part of a larger opposition against the standard.
There are a number of people who seem to think that the standard is,
to various degrees, a pile of shit, and that everything the committee
did was wrong.  At least some of these people seem to have made
uninformed decisions, since they display an ignorance of the actual
contents of the standard.  Perhaps this is also behind some people's
hatred towards trigraphs?  It would be a good idea to post pages 14
and 15 of the Rationale (i.e. the part that discusses trigraphs) so
that people can read about the actual reasoning that led to trigraphs.
Does anybody know whether copyrights and other legal traps permit
this?  If they do, does anybody have it online?  (I'd hate to type it
in, but I'll do it if that's the only legal way to get it posted.)

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
   MS-DOS, you can't live with it, you can live without it.
Newsgroups: comp.lang.c