Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: net.lang.c Subject: Re: sizeof(char) Message-ID: <5141@brl-smoke.ARPA> Date: Mon, 3-Nov-86 12:53:04 EST Article-I.D.: brl-smok.5141 Posted: Mon Nov 3 12:53:04 1986 Date-Received: Tue, 4-Nov-86 05:27:13 EST References: <4617@brl-smoke.ARPA> <657@dg_rtp.UUCP> <55@cartan.Berkeley.EDU> <663@dg_rtp.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 26 In article <663@dg_rtp.UUCP> throopw@dg_rtp.UUCP (Wayne Throop) writes: >True, true. But ANSI is likely to decide that sizeof(char) MUST ALWAYS >BE one (and I think this is universally true on existing >implementations... if I'm wrong, somebody let me know). 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". My proposal would allow implementors the freedom to decide whether supporting this existing practice is more important than the benefits of making a distinction between the two concepts. It is possible to write code that doesn't depend on sizeof(char)==1, and some C programmers are already careful about this. Transition to the more general scheme would occur gradually (if at all) for existing C implementations, with only implementors of systems for the Asian market and of bitmap display architectures initially taking advantage of the opportunity to make these types different sizes.