Newsgroups: comp.lang.c
Path: utzoo!utgpu!jarvis.csri.toronto.edu!dgp.toronto.edu!flaps
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: Long Chars
Message-ID: <8804050101.AA18139@explorer.dgp.toronto.edu>
Organization: University of Toronto
References: <7447@brl-smoke.ARPA> <439@splut.UUCP> <8803250401.AA01184@champlain.dgp.toronto.edu> <7546@brl-smoke.ARPA>
Date:	Mon, 4 Apr 88 19:01:07 EDT


I, flaps@dgp.toronto.edu (Alan J Rosenthal) wrote:

>>Why do you need to make sizeof(char) == 2 just to make chars 16 bits?
>>Make chars 16 bits, keep sizeof(char) == 1, make sizeof(int) == 1, ...

gwyn@brl.arpa (Doug Gwyn) responded:

>The idea is that you not only need to handle fat chars, you also
>have applications that need to handle smaller objects (bytes, or
>bits).  Therefore there would have to be some object type smaller
>than a char (e.g. a "short char").

I now respond:

First of all, why would you possibly want to access bytes?  Bytes are
machine-dependent things with no high-level analogue.  You certainly
might want to access some object which is small enough to use for
traversing an arbitrary object.  16-bit chars would still have this
property so long as all objects were a multiple of 16 bits long.

As for being able to access bits, sizeof(char) would have to be equal
to 8 or 16 for that, not just 2.  Also, creating smaller objects than
chars will cause a lot of other problems, such as requiring either
introducing the concept of alignment into the language (e.g. arguments
to memcpy must be char-aligned) or making the arguments to routines
like memcpy be pointers to this smaller object at the expense that that
incurs.

ajr
-- 
"Comment, Spock?"
"Very bad poetry, Captain."