Confused understanding a passage about char and int types from K&R's "The C Programming Language"

Question

Concerning this passage from Chapter 1: A Tutorial Introduction in Kernighan and Ritchie: The C Programming Language (I've bolded the specific part that I need clarification on and have elaborated down below):

Given getchar and putchar, you can write a surprising amount of useful code without knowing anything more about input and output. The simplest example is a program that copies its input to its output one character at a time: read a character while (character is not end-of-file indicator) output the character just read read a character Converting this into C gives:

#include <stdio.h>
/* copy input to output; 1st version */ main()
{
       int c;
       c = getchar();
       while (c != EOF) {
           putchar(c);
           c = getchar();
       }
}

The relational operator != means "not equal to". What appears to be a character on the keyboard or screen is of course, like everything else, stored internally just as a bit pattern. The type char is specifically meant for storing such character data, but any integer type can be used. We used int for a subtle but important reason.

The problem is distinguishing the end of input from valid data. The solution is that getchar returns a distinctive value when there is no more input, a value that cannot be confused with any real character. This value is called EOF, for ``end of file''. We must declare c to be a type big enough to hold any value that getchar returns. We can't use char since c must be big enough to hold EOF in addition to any possible char. Therefore we use int.

My understanding is that Char is a type of Int, but it is just smaller (in the same way that Int16, Int32, Int64 in other languages are the same but can represent magnitudes of numbers).

I get that every character can be represented by an integer of type Char, so why can't the EOF value be represented as a Char? Is it because every single integer in the Char type is already accounted for, and even one more number is too large for the data type?

Any explanation or corrections to my knowledge would be appreciated.

FWIW, K&R is **not** a good book to *learn* C from in the 21st Century. It's full of cryptic one-liners rather than maintainable code, and deprecated stuff like functions without prototypes (e.g. the example you quoted.) — Oliver Charlesworth, Dec 30 '13 at 15:51
http://stackoverflow.com/questions/562303/the-definitive-c-book-guide-and-list — Oliver Charlesworth, Dec 30 '13 at 15:59
@OliCharlesworth Does what you say about K&R apply to both editions, or just the first? — Dennis Meng, Dec 30 '13 at 18:46
@OliCharlesworth I'll have to dig up my copy of the second edition later, but as I understand it, the second edition uses ANSI C89, which means it's still a little out of date too even if it isn't guilty of the bigger issues. — Dennis Meng, Dec 30 '13 at 18:52

score 8 · Answer 1 · answered Dec 30 '13 at 15:49

8

Is it because every single integer in the Char type is already accounted for, and even one more number is too large for the data type?

Yes, that's exactly correct. To be a little more specific, the whole idea is to define EOF as a value that can be distinguished from any value that getchar could possibly have retrieved from the file. Since you can write any possible value of char to the file, you can also read any possible value of char back from the file. For EOF to do its job correctly, it must be something different from any of those values that could have been written to/read from the file. To do that, it must be a value that can't fit in a char.

answered Dec 30 '13 at 15:49

Jerry Coffin

476,176
80
629
1,111

So if a normal Int is 32 bits, 2^32, and a Char is the same type except the 8 bit version: 2^8 = 256, does that mean that each number for 0 to 256 represents a character, and there are no more/less than those? And also that it's called a Char type because it represents characters, and could just as easily be called Int8? I just want to make sure I'm understanding all of this correctly. – nf7 Dec 30 '13 at 15:55
@nf7: With one minor caveat, yes. The caveat is that the range is 0 to 255, not 0 to 256. In fact, quite a few libraries (e.g., Boost, at least at one time) defined `int8_t` something like: `typedef char int8_t;` – Jerry Coffin Dec 30 '13 at 15:57
Is there a specific reason that the last number is left off? Is the last number let off for acceptable values in other data types/sizes? – nf7 Dec 30 '13 at 16:00
@nf7 256 cannot be represented in 8 bits. It would be `100000000` in binary. – JeremyP Dec 30 '13 at 16:13
@nf7: in N bits you can represent 2^N values. As an unsigned int, those are normally interpreted as 0 through 2^N-1. – Jerry Coffin Dec 30 '13 at 16:15
1

@JerryCoffin there's another more major caveat in that, each byte only represents one character if the character set says so. For e.g., UTF-8 can take 2, 3 or 4 bytes to represent a character. – JeremyP Dec 30 '13 at 16:30

score 1 · Answer 2 · answered Dec 30 '13 at 15:50

The C standard does guarantee that the return value from getchar() is either a valid character or a distinct code. EOF, is not the code for a valid character. EOF expands to an integer constant expression, with type int and might have negative value.

Elliott Frisch · Answer 3 · 2013-12-30T16:17:31.390

1

The issue is that the "C" standard does not specify if the signed-ness of "char". So, while a modern implementation will likely provide "signed" and "unsigned" char; the early standards actually changed (at least twice). The standard also does specify (since 1989), that whatever value EOF has; it's negative.

edited Dec 30 '13 at 16:17

answered Dec 30 '13 at 15:51

Elliott Frisch

198,278
20
158
249

@JerryCoffin Are you certain about that? It's always outside the range of `char`, but I vaguely recall some implementation that returned a value of `257` (I think it was Motorola MVM Unix). – Elliott Frisch Dec 30 '13 at 15:57
@JerryCoffin [C89](http://flash-gordon.me.uk/ansi.c.txt) ANSI X3.159-1989 §4.9.1 "EOF - which expands to a negative integral constant expression that is returned by several functions to indicate end-of-file ,that is, no more input from a stream;" – Elliott Frisch Dec 30 '13 at 16:16
I believe it's legitimate for `char` and `int` to have identical ranges, provided that the implementation does not allow files to contain the `char` value that would represent EOF. On such implementations, `char` must be signed, to ensure that every `char` is representable as an `int`. – supercat Jan 19 '14 at 23:13

score 0 · Answer 4 · answered Dec 30 '13 at 15:49

EOF really means absence of character, and it can thus not be a plain character. While there is the option of singling out a value from the range of char to mark this particular value, having an out-of-range value allows managing 256 uniquely valid characters in any platform in which char is 8 bits. To be able to hold an out of range value, the function must use an integer type that can represent all the values in char and at least one more.

score 0 · Answer 5 · answered Dec 30 '13 at 15:52

The char type can be either signed or unsigned, depending on the implementation, but EOF is commonly defined as -1. If char is unsigned it can't represent a value of -1, and thus getchar() is defined to return an int, which when unqualified is always signed and can thus represent all possible values of char and represent -1 (EOF).

Share and enjoy.

score 0 · Answer 6 · answered Dec 30 '13 at 15:55

My understanding is that Char is a type of Int, but it is just smaller

Yep.

I get that every character can be represented by an integer of type Char, so why can't the EOF value be represented as a Char? Is it because every single integer in the Char type is already accounted for, and even one more number is too large for the data type?

Yep.

score 0 · Answer 7 · answered Dec 30 '13 at 15:57

If you look at the man page for getchar, you can read,

getchar() is equivalent to getc(stdin)

getc() is equivalent to fgetc() except that it may be implemented as a macro which evaluates stream more than once.

fgetc() reads the next character from stream and returns it as an unsigned char cast to an int, or EOF on end of file or error.

The synopsis decalares

SYNOPSIS
   #include <stdio.h>

   int fgetc(FILE *stream);

Therefore c should be declared as an int.

score 0 · Answer 8 · answered Dec 30 '13 at 17:08

By having EOF be outside the range of possible characters, the example code will successfully copy any ("binary") data. There is no chance of EOF being a a valid value in the middle of the data.
The best C language book is by Harbison and Steele, C: A Reference Manual. And I've used them all.

Confused understanding a passage about char and int types from K&R's "The C Programming Language"

8 Answers8