-1

While going through the book by Dennis Ritchie , I found that it is better to storing the value returned by getchar() function in C in integer type variable rather than character type variable. The reason it stated was that character type variable cannot store the value of EOF . While implementing it practically, there was no such difficult in storing the return in char type variable. And What does getchar() function originally returns , the charcter or the ascii value of the character?

Amisha Bansal
  • 11
  • 1
  • 4

2 Answers2

0

EOF is end of file. You won't see the difference until you implement some file read/write operation/code.

saurabh agarwal
  • 2,124
  • 4
  • 24
  • 46
0

The value of EOF is always defined to be -1.

That works well because all ASCII codes are positive, so it can't possibly clash with any real character's representation.

Unfortunately, C has a very strange feature that can cause trouble. It is not defined what the range of possible values for a char variable must be. On some systems it is -128 to +127, which is fine; but on other systems it is 0 to +255, which is fine for normal ASCII values, but not so hot for EOF's -1.

For one thing, the variable to hold getchar()'s return value must be an int. EOF is an out of band return value from getchar(): it is distinct from all possible char values which getchar() can return. (On modern systems, it does not reflect any actual end-of-file character stored in a file; it is a signal that no more characters are available.) getchar()'s return value must be stored in a variable larger than char so that it can hold all possible char values, and EOF.

Two failure modes are possible if, as in the fragment above, getchar()'s return value is assigned to a char.

  • If type char is signed, and if EOF is defined (as is usual) as -1, the character with the decimal value 255 ('\377' or '\xff' in C) will be sign-extended and will compare equal to EOF, prematurely terminating the input.t
  • If type char is unsigned, an actual EOF value will be truncated (by having its higher-order bits discarded, probably resulting in 255 or 0xff) and will not be recognized as EOF, resulting in effectively infinite input.

The bug can go undetected for a long time, however, if chars are signed and if the input is all 7-bit characters. (Whether plain char is signed or unsigned is implementation-defined.)

References:

K&R1 Sec. 1.5 p. 14

K&R2 Sec. 1.5.1 p. 16

ISO Sec.

6.1.2.5, Sec. 7.9.1, Sec. 7.9.7.5

H&S Sec. 5.1.3 p. 116, Sec. 15.1, Sec. 15.6

CT&P Sec. 5.1 p. 70 PCS Sec. 11 p. 157

Generally it is best to store getchar()'s result in an int guaranteeing that EOF is properly handled.

Community
  • 1
  • 1
TryinHard
  • 4,078
  • 3
  • 28
  • 54
  • In theory, EOF only needs to be negative; it does not have to be `-1`. In practice, it always is `-1`. – Jonathan Leffler Jul 01 '15 at 05:40
  • @Tryin "If type char is signed, and if EOF is defined (as is usual) as -1, the character with the decimal value 255 ('\377' or '\xff' in C) will be sign-extended and will compare equal to EOF, prematurely terminating the input.t If type char is unsigned, an actual EOF value will be truncated (by having its higher-order bits discarded, probably resulting in 255 or 0xff) and will not be recognized as EOF, resulting in effectively infinite input." But no such problem is arising when practically executing it. – Amisha Bansal Jul 01 '15 at 06:35
  • 1
    Also what exactly is getchar() function returning - character or ascii value of character? – Amisha Bansal Jul 01 '15 at 06:44
  • It is character and not the ASCII value. – TryinHard Jul 01 '15 at 06:46
  • @Amisha What you are claiming is not true. You are claiming that you can represent 257 distinct values in an 8 bit value. That's because there are 256 `unsigned char` values (assuming 8 bit char) and 1 `EOF` value. – David Heffernan Jul 01 '15 at 07:19
  • @Amisha Please refer http://stackoverflow.com/questions/7622699/what-is-the-ascii-value-of-eof-in-c – TryinHard Jul 01 '15 at 07:26