Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.lang.c
Subject: Re: uses of void
Message-ID: <6311@sun.uucp>
Date: Tue, 19-Aug-86 03:09:34 EDT
Article-I.D.: sun.6311
Posted: Tue Aug 19 03:09:34 1986
Date-Received: Wed, 20-Aug-86 08:23:13 EDT
References: <277@sdchema.sdchem.UUCP> <86900012@haddock> <3121@brl-smoke.ARPA>
Organization: Sun Microsystems, Inc.
Lines: 27

> >The "abstract units" of sizeof() are "char" by definition.  (Too many users
> >have been assuming sizeof(char)==1, so it's official in C++ and ANSI C.
> 
> Don't be too sure that this won't change by the time of the final X3J11
> standard.  The internationalization issue has yet to be resolved, and
> my sense is that the cleanest way to do that will to be to distinguish
> between the basic data chunk size and a datum that can hold a character
> representation.

Not clear.  Widening "char" to support Kanji would be disruptive and cut
performance in applications that need not deal with individual Kanji symbols
as such (rather than treating a 16-bit Kanji symbol as a pair of 8-bit
"characters", as, for instance, the C compiler could in most instances).
The best proposals I've seen are the ones from AT&T-IS that propose a
separate "long char" data type for, well, long characters.  If adding a new
data type is distasteful, one could "typedef" "short" into such a data type,
although you might have to engage in some jiggery-pokery to initialize a
"string" of "short"s from a Kanji string.

You can still distinguish between the unit of storage and the datum used to
hold character representations of, say, Kanji; however, you don't have to do
this by saying "char" will hold those representations, but can provide a new
data type for this.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)