What does getchar return if it reads the "enter"...?

[rahul sinha]

When you type one character and press enter, it prints two values, so it turns out that it does read "enter" from the input buffer. What does getchar actually return on reading enter? Moreover I can't understand why fflush(stdin) doesn't have any effect on the output when you type a string like("bytes")an d then press enter.

#include <stdio.h>
/* count characters in input; 2nd version */
void main()
{
int  nc;
for (nc = 0;getchar()!=EOF;nc++)
{
//fflush(stdin);
printf("%d\n",nc);


//printf("%.0f\n", nc);
}

[horace1]

the ENTER key is a valid ASCII code and is read by getchar(). Try the following fragment of code and you will see its ASCII value

int nc;
char ch;
for (nc = 0;(ch=getchar())!=EOF;nc++)
{
printf("%d %d\n",nc, ch);

the fflush() function operates when you have writen and wish to write the information to the file, for a detailed explaination see

http://www.cplusplus.com/reference/clibrary/cstdio/fflush/

[Banfa]

getchar returns int and EOF is an int constant. You should not cast the return value of getchar to char, either explicitly or implicitly (by for example assigning it to a variable of type char) before comparing it to EOF.

read this

[rahul sinha]

@banfa i dont think there is any problem in casting the return value of getchar,,,first of all getchar returns unsigned int,not just any int(yeah it returns negative value in case of end of file..)moreove in case of character to integrs type conversion,ther e is never of problem ...u can always cast a character to integer and integer to a character.....

[weaknessforcats]

there is never of problem ...u can always cast a character to integer and integer to a character.....

This is not true. An int is bigger than a char so a large value in an int won't fit in the char. While the compiler will let you do the cast, the result is indeterminate and it is up to you to know if the value in the char is correct.

[rahul sinha]

yeah u r right...char range from -128 to 127..its okay but in the question getchar() returns unsigned integer value of characters only..so there should be no problem in casting.....

[donbock]

Banfa's point was that you need to compare the getchar return value to EOF before you cast the return value to char. That's because the integer code for EOF is guaranteed to not fit in a plain char; thus casting EOF to char will corrupt the value.

It is true that any value returned by getchar other than EOF can indeed be cast to char without corrupting the value.

[rahul sinha]

@donbock but eof=-1,and even char can be negative,,then howcome,,,casti ng is wrong..........

[donbock]

I don't know about C++, but the C Standard requires that EOF "expands to an integer constant expression, with type int and a negative value". It may commonly be -1, but there is no requirement that it be that particular negative integer.

The getchar function either returns a character from the input stream or EOF. If EOF had the same value as a valid character then that particular valid character would always be mistaken for EOF. Thus, the value of EOF must be outside the range of the valid characters. I suspect you will find that plain char is unsigned in implementations where EOF is -1; and that EOF has some other negative value in implementations where plain char is signed.

[horace1]

EOF is system dependent so long as it is not equal to any of the valid character codes (but is commonly -1)

[rahul sinha]

okay i got it what you are trying to say is that,there is no character corresponding,. .to eof.....so we cant compare a character to eof..hmmm,but when eof is -1 and char range from -128 to +127 ,,then there has to be some character corresponding to -1 no...

[donbock]

My point was that I don't believe your combination ("eof is -1 and char range from -128 to +127") is possible. As I said above, "I suspect you will find that plain char is unsigned in implementations where EOF is -1; and that EOF has some other negative value [not -1] in implementations where plain char is signed".

[Banfa]

No we are not saying there is no character corresponding to EOF (when EOF is -1 and char is signed).

We are saying the reverse that there is a character that corresponds to EOF if you have truncated it to char so if that character appears in the stream you will get a premature and false positive on the comparison to EOF.

Alternatively if char is unsigned when you truncate the returned EOF value to char and the re-extended to compare to EOF there is no sign extension of the unsigned value and you compare 255 to -1 resulting in the stream IO operation not ending even though EOF has been read.

Try reading the page I linked to.

The point is that EOF is explicitly of type int to place it outside the range of values that can be represented with a char (an int having normally at least 8 more bits than a char). For robust and portable code that will work into the future you need to compare to EOF while the type is still an int and only after you are sure it is not EOF convert to a char.

[rahul sinha]

thanking bonfa and donback for your replies,i think i have got it..you are saying that:-
if char is unsigned then comparison of ch with eof(always negative)....wi ll nver cause the loop to end...and if eof is within a valid character range,then...so me character will be mistakenly taken as
eof......did i get it right now... :)

[Banfa]

Yes .