Checksum: 61567
Lines: 29
Path: utzoo!sq!msb
From: msb@sq.uucp (Mark Brader)
Date: Thu, 10-Mar-88 14:18:36 EST
Message-ID: <1988Mar10.141836.9084@sq.uucp>
Newsgroups: comp.lang.c
Subject: Re: sizeof(char)
References: <11702@brl-adm.ARPA> <243@eagle_snax.UUCP> <2245@geac.UUCP> <2809@haddock.ISC.COM> <17395@watmath.waterloo.edu>
Reply-To: msb@sq.UUCP (Mark Brader)
Organization: SoftQuad Inc., Toronto

Ray Butterworth (rbutterworth@watmath.waterloo.edu), with whom I usually
agree, writes:

> The Honeywell Bull GCOS-8 C compiler packs chars into individual [9-bit]
> bytes for arrays and structure, but individual external, static, or auto
> char variables occupy a full word. ... Certainly as far as this machine is
> concerned, there is no reason to say that sizeof(char) should be 1 ...

If chars in arrays and structures occupy 1 byte, sizeof(char) is 1.
That the machine chooses to align char scalars on word boundaries
is irrelevant.  Of course, if unsigned char scalars are then allowed to take
on values in excess of 512, the implementation is buggy.  [C defines overflow
semantics for unsigned types only.]

> If C left the units of sizeof up to the implementor it would solve
> a lot of problems ...
> Other than allowing sloppily written code to continue to be written,
> I can see no reason whatsoever for requiring that sizeof(char) be 1.

It is true that K&R appendix A noted that sizeof(char) is 1 only "in all
existing implementations" (page 188), while it is only in the main part
of the Book, which is not definitive, that this qualification is omitted
(page 126).  However, I think that the sizeof(char) assumption is *now*
so widespread that it must indeed be enshrined in the coming standard,
just like the description of the C library.

Mark Brader		"The default choice ... is in many ways the most
utzoo!sq!msb		 important thing.  ... People can get started without
msb@sq.com		 reading a big manual."		-- Brian W. Kernighan