Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Long Chars
Message-ID: <7586@brl-smoke.ARPA>
Date: 30 Mar 88 17:05:06 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: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 18

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.

sizeof(bit)==1 can be guaranteed universally.

If you mean addressable object, there is no single size universally
supported by computer hardware.

The problem with preempting "char" for small objects is that most C
code thinks that a "char" is big enough to hold a primitive unit of
text.  This is plainly wrong in some environments unless "char" is
made pretty large.  (It needs to be 16 bits for Imagen's GASCII, for
example.)  "char" cannot play both roles at once, and "long char" is
contrary to the current use of "char" majority of existing code (as
well as requiring a whole slew of lstr*() library functions).