sizeof(char)

Daniel R. Levy levy at ttrdc.UUCP
Wed Nov 5 15:53:48 AEST 1986


In article <5141 at brl-smoke.ARPA>, gwyn at 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



More information about the Comp.lang.c mailing list