Re: [TUHS] v7 K&R C

[Brantley Coile <brantley@coraid.com>]

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@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@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 */