Path: utzoo!mnetor!uunet!husc6!mailrus!ames!necntc!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Long Chars
Message-ID: <3243@haddock.ISC.COM>
Date: 30 Mar 88 19:36:09 GMT
References: <7447@brl-smoke.ARPA> <439@splut.UUCP> <8803250401.AA01184@champlain.dgp.toronto.edu> <7546@brl-smoke.ARPA> <4191@ihlpf.ATT.COM>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 17
Summary: Char means three things

In article <4191@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704a-Liber,N.J.) writes:
>There is a need for having a fundamental type (call it foo) such that
>sizeof(foo) == 1 can be guaranteed in *ALL* implementations.  Due to
>existing practice, I would like that type to be called char.  Just add
>things like 'long char' to accomodate the people who need them.

The problem is that there are three distinct types of objects (small integers,
allocation quanta, and characters), all of which have traditionally been
called "char".  We can't keep existing practice on all three, and still have
useful programs in large-alphabet environments.

The current dpANS still equates the first two, but has created wchar_t for the
third.  I'm seriously considering adopting a convention that eschews all use
of the word "char" (much as some people avoid "int") in favor of a good set of
typedefs.  (Certainly I'd change this for "D".)

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint