Chinaunix首页 | 论坛 | 博客
  • 博客访问: 279503
  • 博文数量: 101
  • 博客积分: 4245
  • 博客等级: 上校
  • 技术积分: 1085
  • 用 户 组: 普通用户
  • 注册时间: 2009-04-24 00:28
文章分类

全部博文(101)

文章存档

2012年(1)

2011年(16)

2010年(34)

2009年(50)

我的朋友

分类: C/C++

2010-03-15 19:12:14

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.

  1. 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. [footnote]
  2. 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.)

阅读(1503) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2010-04-24 02:07:29

Many chinese text book use char to receive the return value.