Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!mimsy!eneevax!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.lang.c
Subject: Re: Stop adding types, Let's remove Trigraphs instead!!
Message-ID: <5900@brl-smoke.ARPA>
Date: Thu, 28-May-87 01:16:31 EDT
Article-I.D.: brl-smok.5900
Posted: Thu May 28 01:16:31 1987
Date-Received: Sat, 30-May-87 11:20:34 EDT
References: <7264@brl-adm.ARPA> <734@sdchema.sdchem.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 32

In article <5899@brl-smoke.ARPA> I wrote:
>I've threatened to publish a portable (ANSI C!)
>preprocessor that will process portable ANSI C source text files and
>substitute normal C source code characters for trigraphs.

I should have pointed out that the point of my threat is that the
dpANS GUARANTEES that I will be able to implement this portably
(in a hosted environment, of course), thereby reinforcing my
position that this issue is environmental.  Note that the dpANS
does not specify the particular character set encoding, for reasons
that should apply equally well to (not) specifying the characteristics
of text output devices.  It is implied that the set of glyphs set
forth for the C source character set in the ANS is somehow the
"official" set, but of course few sites (other than those with
Imagen 300dpi laser printers and a particular version of UNIX DWB)
will be able to exactly reproduce the glyphs.  Most will settle for
a good approximation.  What is considered to be a good approximation
is really not the business of the ANS, just as magtape source
interchange formats are outside the scope of the ANS.

I am particularly sensitive to these issues since I'm implementing
cryptanalytic software, where one has to be careful to properly
distinguish between encodings of alphabets, normal alphabets, etc.
For example, the glyph "J9" may be used to represent a single
letter, even though the underlying language does not normally
use that glyph for a letter.  This strikes me as quite analogous
to having locally-encoded "??!" (if that's what a site chooses to
use; frankly, I think they would invariably use something better)
represent the underlying "|" character of the normal C "plain-text"
alphabet.  (By the way, I'm not at all sure that ??!c stands for |p;
I left the dpANS at work and that detail doesn't matter for purposes
of this discussion.)