16 May
2020
16 May
'20
6:57 a.m.
I always kept local, single characters in ints. This avoided the problem with loading a
character being signed or unsigned. The reason for not specifying is obvious. Today, you
can pick the move-byte-into-word instruction that either sign extends or doesn't. But
when C was defined that wasn't the case. Some machines sign extended when a byte was
loaded into a register and some filled the upper bits with zero. For machines that filled
with zero, a char was unsigned. If you forced the language to do one or the other, it
would be expensive on the opposite kind of machine.
It's one of the things that made C a good choice on a wide variety of machines.
I guess I always "saw" the return value of the getchar() as being in a int sized
register, at first namely R0, so kept the character values returned as ints. The actual
EOF indication from a read is a return value of zero for the number of characters read.
But I'm just making noise because I'm sure everyone knows all this.
Brantley
On May 15, 2020, at 4:18 PM, ron(a)ronnatalie.com
wrote:
EOF is defined to be -1.
getchar() returns int, but c is a unsigned char, the value of (c = getchar()) will be
255. This will never compare equal to -1.
Ron,
Hmmm... getchar/getc are defined as returning int in the man page and C is traditionally
defined as an int in this code..
On Fri, May 15, 2020 at 4:02 PM <ron(a)ronnatalie.com> wrote:
> Unfortunately, if c is char on a machine with unsigned chars, or it’s of type
unsigned char, the EOF will never be detected.
>
>
>
>> • while ((c = getchar()) != EOF) if (c == '\n') { /* entire record is
now there */