Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!gwyn@BRL.ARPA
From: gwyn@BRL.ARPA (VLD/VMB)
Newsgroups: net.lang.c
Subject: Re:  Problem with the C pre-processor
Message-ID: <1916@brl-tgr.ARPA>
Date: Sat, 5-Oct-85 19:51:51 EDT
Article-I.D.: brl-tgr.1916
Posted: Sat Oct  5 19:51:51 1985
Date-Received: Mon, 7-Oct-85 02:50:08 EDT
Sender: news@brl-tgr.ARPA
Lines: 19

If the target environment cannot support the full C character set
then it obviously cannot support an X3J11 implementation.

I was told that several committee members wanted to specify ASCII
for the character set, and that the current tip-toeing around the
issue was a compromise consensus.  The thing is, you see, ASCII
is an official standard and EBCDIC was just IBM doing its own
thing, as usual.  The properties of EBCDIC are pretty disgusting,
from a programmer's viewpoint.

I once had to cope with this issue, and decided the best thing was
to insist on all characters available inside a running program
being ASCII, with all characters outside the program being
expressed in some "host character set".  I used the toascii()
function to map into internal (ASCII) form and a new function
tohostc() to map to external (host) form.  this made it possible
to use the nice properties of the ASCII character set in my code.
On an ASCII host, these are trivial macros, and on other hosts
they are just indexed translation tables.