Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: sizeof(char)
Message-ID: <7434@brl-smoke.ARPA>
Date: 10 Mar 88 22:08:16 GMT
References: <11702@brl-adm.ARPA> <243@eagle_snax.UUCP> <2245@geac.UUCP> <2809@haddock.ISC.COM> <17395@watmath.waterloo.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20

In article <17395@watmath.waterloo.edu> rbutterworth@watmath.waterloo.edu (Ray Butterworth) writes:
>If C left the units of sizeof up to the implementor it would solve
>a lot of problems (e.g. none of the multi-byte character mess that
>is now in the proposed standard, and the problems of having to have
>functions that know about the two different types of strings).

>Other than allowing sloppily written code to continue to be written,
>I can see no reason whatsoever for requiring that sizeof(char) be 1.
>In Japan it could be 2, while on machines that do a lot of bit
>manipulation it could be 16.  Both are appropriate for their needs.

Yes!  I would appreciate it if you would send in a comment suggesting
that the approach in X3J11/86-205 (my sizeof(short char)==1 proposal)
should be considered in place of the proposed multi-byte character
support.  That is somewhat more ambitious than your sizeof(char)>=1
proposal, in that it provides an extra data type, so if that bothers
you you could suggest merely that the requirement sizeof(char)==1 be
dropped (which would leave the door open for later adoption of
something ling X3J11/86-205, but unfortunately would not eliminate
the proposed multi-byte character features).