Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!clyde!cuae2!ltuxa!ttrdc!levy
From: levy@ttrdc.UUCP (Daniel R. Levy)
Newsgroups: net.lang.c
Subject: Re: sizeof(char)
Message-ID: <1294@ttrdc.UUCP>
Date: Wed, 5-Nov-86 00:53:48 EST
Article-I.D.: ttrdc.1294
Posted: Wed Nov  5 00:53:48 1986
Date-Received: Thu, 6-Nov-86 01:04:07 EST
References: <4617@brl-smoke.ARPA> <657@dg_rtp.UUCP> <55@cartan.Berkeley.EDU> <663@dg_rtp.UUCP> <5141@brl-smoke.ARPA>
Organization: AT&T, Computer Systems Division, Skokie, IL
Lines: 33

In article <5141@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
>X3J11 as it stands requires sizeof(char)==1.  I have proposed that
>this requirement be removed, to better support applications such as
>Asian character sets and bitmap display programming.  Along with
>this, I proposed a new data type such that sizeof(short char)==1.
>It turns out that the current draft proposed standard has to be
>changed very little to support this distinction between character
>objects (char) and smallest-addressable objects (short char).  This
>is much better, I think, than a proposal that introduced (long char)
>for text characters.
>
>Unfortunately, much existing C code believes that "char" means "byte".
>
>It is possible to write code that doesn't depend on sizeof(char)==1,
>and some C programmers are already careful about this.

A question:  what about the jillions of C programs out there which
declare "char *malloc()"?  Will they all need to be changed?  Common
sense says no, since malloc() is supposed to return a "maximally aligned"
address anyhow, so as far as anyone cares it could be declared float * or
double * or short int * or (anything else)*  if malloc() in the malloc() code
itself were declared the same way.  So if "char" happened to be a two byte
quantity, no sweat, right?  Or was there any particular reason for declaring
malloc() to be a "char *"?   And thus, might something break in malloc() or
the usage thereof if char might no longer be the smallest addressable quantity?
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
	   go for it!  			allegra,ulysses,vax135}!ttrdc!levy