Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: Indefinite-length array as member of struct; sizeof(char)
Message-ID: <10560@smoke.BRL.MIL>
Date: 19 Jul 89 13:40:56 GMT
References: <7360@c3pe.UUCP| <821@fozzy.UUCP> <14474@dartvax.Dartmouth.EDU> <786@mitisft.Convergent.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 29

In article <786@mitisft.Convergent.COM> kemnitz@mitisft.UUCP (Greg Kemnitz) writes:
>Since I have not used an ANSI C compiler, I don't know what ANSI says about
>sizeof(char), but if it is not 1 the ANSI committee should all be fired :-).

The proposed Standard does require that sizeof(char)==1.  Good arguments
can be (and were) made against this, but X3J11 decided that too many
existing applications had been relying on this property (which had never
previously been guaranteed, but happened to almost universally be the
case).  If the Committee had bought into the notion of "short char" for
byte-sized objects, then it would have been essential to not insist on
sizeof(char)==1.  However, instead they settled on the "wide character"
approach, which was closer to what vendors had already been attempting
to do to support international character sets.  Thus, "char" and byte
are essentially synonymous in Standard C.

>The only other size definition I have seen (this has been talked about at
>length on another thread) is
>sizeof char <= sizeof short <= sizeof int <= sizeof long

The proposed Standard also specifies minimum sizes (in terms of the minimum
range of representable values) for each of these types and their unsigned
counterparts.  It boils down to:
	char: at least 8 bits
	short: at least 16 bits
	int: at least 16 bits
	long: at least 32 bits

There are similar, although more involved, requirements for floating-point
representations.