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: Must sizeof(int) exceed sizeof(char) in hosted environments?
Message-ID: <11048@smoke.BRL.MIL>
Date: 13 Sep 89 08:35:53 GMT
References: <1989Aug29.204254.3307@sq.sq.com> <1713@cbnewsl.ATT.COM> <10908@smoke.BRL.MIL> <9487@cbnews.ATT.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 25

In article <9487@cbnews.ATT.COM> mark@cblpf.ATT.COM (Mark Horton) writes:
>The obvious reason why you would want big characters (other than tiny
>8 bit machines) is to support eastern character sets, ...

Yes, but the "international" community bought into "multibyte characters"
instead of fat implementation of char.  I happen to think that was a poor
decision, because it requires additional programming to properly deal
with such environments.  Fat "char" would be slicker, but if you want
that you also need some way to express "small char" too, and my proposal
for that was not adopted.  Therefore I doubt that many implementations
will actually implement char any fatter than 8 or 9 bits, even in Eastern
markets.

>I would discourage any implementation of unsigned from ignoring or clearing
>the high bit.

They're not allowed to do that already.

>I think the "assume you won't see the EOF bits in the file"
>approach is right for the implementation, while it's better for the
>application to use feof instead of EOF.

That seems to be the conclusions we've arrived at.  It is unfortunate
that comparing (getchar() == EOF) is not as universal as we've come
to believe.