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