Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: C on IBM machines
Message-ID: <13919@smoke.BRL.MIL>
Date: 21 Sep 90 22:06:56 GMT
References: <1762 <268@cadlab.sublink.ORG> <18089@haddock.ima.isc.com>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 16

In article <18089@haddock.ima.isc.com> karl@kelp.ima.isc.com (Karl Heuer) writes:
>Ideally, yes.  Though if you inherit a bunch of ASCII-specific code, it may
>well turn out that the path of least resistance is to use an implementation
>that emulates ASCII via transliteration inside the I/O calls.

Or, the application could explicitly map between the native host character
set and ASCII.  I've found the following "functions" useful over the years:

/* integer (or character) arguments and value: */
#define fromhostc( c )	(c)		/* map host char set to ASCII */
#define tohostc( c )	(c)		/* map ASCII to host char set */

The definitions of these are, of course, tailored to the environment.
The above are the trivial versions when the native character set is
already ASCII.  In an EBCDIC environment they would index a translation
table (much like the typical implementation of the <ctype.h> macros).