Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: sizeof in 36-bits machines
Message-ID: <11300@smoke.BRL.MIL>
Date: 16 Oct 89 04:17:55 GMT
References: <272@ssp1.idca.tds.philips.nl> <11284@smoke.BRL.MIL> <398@cpsolv.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 29

In article <398@cpsolv.UUCP> rhg@cpsolv.uucp (Richard H. Gumpertz) writes:
>I see no reason that char could not be 8 bits on a PDP-10.  sizeof(long) might
>then be 4.  There is nothing in C that talks about the bit-size of any type
>being a multiple of the bit-size of char.

Wrong.  "Except for bit-fields, objects are composed of contiguous
sequences of one or more bytes, ..." (Section 1.6).  And "byte",
"character", and "char" are defined as denoting essentially the same
thing (differing only in the property being emphasized).

>There is nothing that prohibits extra bits between chars (e.g. the low-order
>4 bits for PDP-10 style 8-bit chars) as long as the addressing mechanism
>skips over them.

This is allowed ONLY if the "extra" bits are also skipped in accessing
integer, etc. data.  In other words, the implementor need not use all the
bits in a word, but if he's going to ignore some of them in the char array
context, he must ignore them also in other contexts.  It would seem to be
a pretty dumb implementation decision to do that.

>I forget whether char must hold at least 8 bits ...

Yes, the Standard in effect requires that a char/byte have at least 8 bits.

>Alternatively, you could just make sizeof(int)=sizeof(char)=1

An implementor can do that, and it might be a reasonable choice on a word-
oriented machine where byte extraction is horribly expensive and there is
plenty of memory available for applications.