Undelivered mail

MAILER%ALASKA.BITNET at CUNYVM.CUNY.EDU MAILER%ALASKA.BITNET at CUNYVM.CUNY.EDU
Sat Mar 12 15:19:33 AEST 1988


Subject:  Re: sizeof(char)

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C at BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 6374
          for SXJVK at ALASKA; Fri, 11 Mar 88 19:49 AST
Received: by UWAVM (Mailer X1.25) id 4203; Fri, 11 Mar 88 20:38:02 PST
Date:         Wed, 9 Mar 88 17:52:54 GMT
Reply-To:     Info-C at BRL.ARPA
Sender:       Info-C List <INFO-C at NDSUVM1>
From:         Ray Butterworth <rbutterworth at watmath.waterloo.EDU>
Subject:      Re: sizeof(char)
Comments: To: info-c at brl-smoke.arpa
To:           Vic Kapella <SXJVK at ALASKA>

In article <2809 at haddock.ISC.COM>, karl at haddock.ISC.COM (Karl Heuer) writes:
> >In article <1988Feb25.202237.8688 at utzoo.uucp> henry at utzoo.uucp (Henry
 Spencer) writes:
> >>Most machines cannot handle bits with anywhere near the efficiency
> >>with which they handle bytes; the appropriate base unit for efficient code
> >>*is* the byte.
>
> "Word-addressible cannot handle bytes with anywhere near the efficiency
> with which they handle words; the appropriate base unit for efficient code
> is the word."  Right?
>
> On a word-addressible machine, there is a perceived need to address objects
> smaller than one word; hence most C compilers give you access to individual
> bytes via "char".  (There may be some that define char as a machine word, but
> I'm not familiar with any.)  Similarly, on byte-addressible machines there is
> a (less) perceived need to address objects smaller than one byte.

The Honeywell Bull GCOS-8 C compiler packs chars into individual bytes
for arrays and structure, but individual external, static, or auto char
variables occupy a full word.  Accessing words (36 bits) on this machine
is easy.  Accesing individual bytes is not (typically a 3 word instruction
is needed to access individual bytes).

Certainly as far as this machine is concerned, there is no reason to
say that sizeof(char) should be 1, any more than it should be 9.

If C left the units of sizeof up to the implementor it would solve
a lot of problems (e.g. none of the multi-byte character mess that
is now in the proposed standard, and the problems of having to have
functions that know about the two different types of strings).

Other than allowing sloppily written code to continue to be written,
I can see no reason whatsoever for requiring that sizeof(char) be 1.
In Japan it could be 2, while on machines that do a lot of bit
manipulation it could be 16.  Both are appropriate for their needs.
Compiler writers that want to continue to support their old code
that assumed sizeof(char)==1 are free to write their compilers with
that same assumption.  But requiring sizeof(char)==1 on all compilers
imposes a needless limit on the language and forces implementors to
use various messy kluges and indefficiencies.



More information about the Comp.lang.c mailing list