Undelivered mail

MAILER%ALASKA.BITNET at CUNYVM.CUNY.EDU MAILER%ALASKA.BITNET at CUNYVM.CUNY.EDU
Sun Mar 13 07:06:00 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 8371
          for SXJVK at ALASKA; Sat, 12 Mar 88 11:35 AST
Received: by UWAVM (Mailer X1.25) id 5676; Sat, 12 Mar 88 12:33:42 PST
Date:         Fri, 11 Mar 88 11:22:58 GMT
Reply-To:     Info-C at BRL.ARPA
Sender:       Info-C List <INFO-C at NDSUVM1>
From:         Rahul Dhesi <dhesi at bsu-cs.uucp>
Subject:      Re: sizeof(char)
Comments: To: info-c at BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK at ALASKA>

Ray Butterworth:
     Other than allowing sloppily written code to continue to be
     written, I can see no reason whatsoever for requiring that
     sizeof(char) be 1.

Doug Gwyn:
     Yes!  I would appreciate it if you would send in a comment...

Please don't do this.  Code that conforms to K&R should not be called
sloppy.  From page 126:

     The size is given in unspecified units called "bytes," which are
     the same size as a char.

Existing code will break if sizeof(char) != 1, and let's not blame the
programmer for simply taking K&R at face value.  And nowhere do I find
K&R saying that byte == char == 1 unit is simply a compiler peculiarity
and not a design assumption in the language.  I have always believed,
and I'm sure others share this reasonable belief, that the C
programming language is defined by all of K&R, and not just by the
brief semi-formal reference manual in the back of the book.

I think "long char" is a better bet than changing the meaning of
"char".  Simply making "char" into two bytes will not allow
new code, that needs long characters, to be usable with old compilers
anyway.  So there is no great need to continue to use the type "char"
for long characters (and it could be deceptive to do so).  With "long
char" one would simply need a new set of str functions such as
lstrcmp(), lstrcpy(), etc.  So long as we need long chars, and also
wish to permit short chars to be used for storage economy, we cannot
avoid having two sets of string functions anyway.

There is precedence for this sort of change in seek() going to lseek().
--
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi



More information about the Comp.lang.c mailing list