K&R C Programming Language 1.5.1 (File Copying) [duplicate]

帅比萌擦擦* 提交于 2019-12-02 09:32:24

So i modified source from int to char to see what is the problem, about taking EOF values... but there is no problem. Works the same way

I happens to work the same way. It all depends on the real type of char, i.e. if it's signed or unsigned. There's also a C FAQ about this very subject. You're more likely to see the bug if your chars are unsigned.

The bug can go undetected for a long time, however, if chars are signed and if the input is all 7-bit characters.

EDIT

The last question is: char type is one byte long, and int is 4bytes long. So, char will only take one ascii character. But if i type "stack overflow is over 1byte long", the output will be "stack overflow is over 1byte long". Where is "tack overflow is over 1byte long" stored, and how does putchar, puts an entire string

Each character will be stored by c in turn. So the first time, getchar() will return s, and putchar will send it on its way. Then t will come along and so on. At no point will c store more than one character. So although you feed it a large string, it deals with it by eating one character at a time.

Separating into two answers:

Why int and not char

Short and formal answer: if you want to be able to represent all real characters, and another non-real character (EOF), you can't use a datatype that's designed to hold only real characters.

Answer that can be understood but not entirely accurate: The function getchar() returns the ASCII code of the character it reads, or EOF.

Because -1 casted to char equals 255, we can't distinguish between the 255-character and EOF. That is,

char a = 255;
char b = EOF;
a == b // Evaluates to TRUE

but,

int a = 255;
int b = EOF;
a == b // Evaluates to FALSE

So using char won't allow you to distinguish between a character whose ASCII code is 255 (which could happen when reading from a file), and EOF.

How come you can use putchar() with an int

The function putchar() looks at its parameter, sees a number, and goes to the ASCII table and draws the glyph it sees. When you pass it an int, it is implicitly casted to char. If the number in the int fits in the char, all is good and nobody notices anything.

If you are using char to store the result of getchar(), there are two potential problems, which one you'll meet depend on the signedness of char.

  • if char is unsigned, c == EOF will never be true and you'll get an infinite loop.

  • if char is signed, c == EOF will be true when you input some char. Which will depend on the charset used; in locale using ISO8859-1 or CP852 it is 'ÿ' if EOF is -1 (the most common value). Some charset, for instance UTF-8, don't use the value (char)EOF in valid codes, but you rarely can guarantee than your problem will stay on signed char implementation and only be used in non problematic locales.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!