From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.lang.c
Subject: Re: Questions about token merging and trigraphs
Date: 20 Dec 92 23:25:59 GMT
Organization: McGill Research Centre for Intelligent Machines

In article <iJqwVB1w165w@quest.UUCP>, kdq@quest.UUCP (Kevin D. Quitt) writes:
> tanner@cdis-1.compu.com (Dr. T. Andrews) writes:
>>> What are trigraphs?
>> Trigraphs are an unpleasant invention from the successor to the
>> horse committee...
> Perhaps Dr. Andrews should spend a little time in thought before
> lashing out at necessary and occasionally useful, if obscure, parts
> of C.

Necessary?  The problem they are intended to solve needs solving.  The
solution does not have to be trigraphs.  Thus, I don't believe they are
necessary.

Occasionally useful?  Certainly.
Obscure?  Definitely.
Occasionally dangerous?  That too.

> Trigraphs are the *only* way to represent certain critical characters
> on machines that do not support the ASCII character set.

Not at all.  There are plenty of other ways of representing them, such
as their canonical ISO Latin-1 names, which require only uppercase
English alphabetics and a few other extremely common characters like
hyphen and space.  Trigraphs are merely a reasonably compact and
marginally readable representation that doesn't clash *too* badly with
the rest of C.

There is, however, no necessity whatever for them to have been made
part of the standard.  All that was really needed was a note that in
environments where the necessary characters are not all available, some
encoding of the missing ones will be necessary, and a specification
that any such encoding takes place before any other processing (as
current trigraphs do), perhaps with a recommended encoding for
environments where the invariant character set is available.  The
specification of an interchange format - perhaps the current trigraph
coding - would also have been a good idea.

That's all that was really needed.  Every specification like this has a
"native" character set, which it is most at home in: in this case,
history forced this to be ASCII (less a couple of characters, like @).
All environments without this set avaiable must use kludges of various
degrees of unpleasantness.  There is absolutely no excuse for forcing
people using the native environment to see the kludges used by others.

In my opinion, a compiler with no way to disable trigraph processing is
simply broken, and a compiler that enables them by default is
defective.  Unless, of course, it is running in an environment where
the trigraphed characters do not exist.

> The cost of something unexpected in an error string is a fairly small
> price to pay for allowing non-ASCII machines to support portable C
> code; after all, *code* isn't going to break.

Yeah, right.  As if double-quoted strings weren't part of code.

My own contribution to the list of possibly-broken code, and yes, I
*know* there are plenty of workarounds:

/* Control values for the ALU emulator */
/* these are the values fed to the ALU control lines */
/* values not defined require use of the C and D inputs,
   which this emulator does not provide. */
#define OP_NOT 3
#define OP_AND 7
#define OP_OR 9
#define OP_NEG 11
#define OP_NOP 15
char opletters[] = "???!???&?|?-???+";

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
Xref: sparky comp.lang.c:18303 comp.unix.ultrix:8863 comp.unix.programmer:5675