getchar() problem

[Senthil-Raja]

The getchar() function is expected to fetch the next character in the
input stream and return it.

But, when I wrote a program using this function, it looks like the
reading of the input stream happens only after I press the ENTER key.

Please someone explain why this is happening.

Regards,
Senthil-Raja.

 

[Chris Dollin]

The getchar() function is expected to fetch the next character in the
input stream and return it.

But, when I wrote a program using this function, it looks like the
reading of the input stream happens only after I press the ENTER key.

Please someone explain why this is happening.

Your input is line-buffered. This is common. See the FAQ.

 

[Dale Henderson]

SR> The getchar() function is expected to fetch the next character
SR> in the input stream and return it.

SR> But, when I wrote a program using this function, it looks like
SR> the reading of the input stream happens only after I press the
SR> ENTER key.

SR> Please someone explain why this is happening.

SR> Regards, Senthil-Raja.

The short answer is buffering. Basically collects an entire line of
input before it sends it to your program.

You should also read question 19.1 in the c FAQ at c-faq.com.
(at least I as I think thats the right question. I couldn't get
c-faq.com to load and used an outdated copy at
http://www.faqs.org/faqs/C-faq/faq/)

 

[Mark McIntyre]

The getchar() function is expected to fetch the next character in the
input stream and return it.

But, when I wrote a program using this function, it looks like the
reading of the input stream happens only after I press the ENTER key.

thats how getchar() works. This is a FAQ.


--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Army1987]

The getchar() function is expected to fetch the next character in the input stream and return it.

But, when I wrote a program using this function, it looks like the reading of the input stream happens only after I press the
ENTER key.

Please someone explain why this is happening.

No. The stuff you type on your keyboard (or whatever input device)
only reaches the input stream when you press ENTER. getchar() will
read the characters as soon as possible.
For example:

#include <stdio.h>
int main(void)
{
int ch;
while (ch = getchar() > EOF)
putchar(ch);
putchar('\n');
return 0;
}
will display *every* character you type, even if not immediately.

 

[Richard Heathfield]

Army1987 said:

For example:

#include <stdio.h>
int main(void)
{
int ch;
while (ch = getchar() > EOF)
putchar(ch);
putchar('\n');
return 0;
}
will display *every* character you type, even if not immediately.

No, it won't. Finding out why not is left as an exercise.

 

[Army1987]

Army1987 said:

while ((ch = getchar()) > EOF)

No, it won't. Finding out why not is left as an exercise.

Darn it...

 

[Christopher Benson-Manica]

while (ch = getchar() > EOF)

while( (ch=getchar()) > EOF)

putchar(ch);

will display *every* character you type, even if not immediately.

It will after you correctly account for operator precedence.

 

[Richard Tobin]

while( (ch=getchar()) > EOF)

I suppose this is technically correct, modulo the usual question of
what happens if sizeof(int)==1, but it's terrible style. The value of
ch is either a legal character or EOF, so the natural idiom is

while( (ch=getchar()) != EOF)

Using > instead of != in this case is an insult to the reader.

-- Richard

 

[Eric Sosman]

Christopher Benson-Manica wrote On 06/21/07 17:10,:

while( (ch=getchar()) > EOF)



It will after you correctly account for operator precedence.

Odd: I tried e corrected version and typed
eleven aracters, but e program only displayed
five (including e newline in bo counts). at
caused is bug?

 

[Richard Tobin]

Odd: I tried e corrected version and typed
eleven aracters, but e program only displayed
five (including e newline in bo counts). at
caused is bug?

You need to be more careful with that stty command.

As Eric is (I think) pointing out, an important reason for line
buffering is that it allows the operating system to provide line
editing, rather than requiring each program to do it.

-- Richard

 

[Richard Tobin]

I felt that > was unlikely to be correct, but I didn't feel confident
enough to make the change without hitting the references. My
apologies.

My criticism was not aimed at you.

-- Richard

 

[Christopher Benson-Manica]

I suppose this is technically correct, modulo the usual question of
what happens if sizeof(int)==1, but it's terrible style. The value of
ch is either a legal character or EOF, so the natural idiom is

while( (ch=getchar()) != EOF)

Using > instead of != in this case is an insult to the reader.

I felt that > was unlikely to be correct, but I didn't feel confident
enough to make the change without hitting the references. My
apologies.

 

[Coos Haak]

Op Thu, 21 Jun 2007 22:17:43 +0200 schreef Army1987:

while ((ch = getchar()) > EOF)

while ((ch = getchar()) != EOF)
Consider signed chars and a char with value less than EOF ;-)

 

[Richard Tobin]

while ((ch = getchar()) > EOF)

[/QUOTE]

while ((ch = getchar()) != EOF)
Consider signed chars and a char with value less than EOF ;-)

getchar() returns either EOF or the character "as an unsigned char
converted to an int", so even if the character is negative as a signed
char, the value returned by getchar() will be positive. Since EOF is
negative, the code is correct. It's just unhelpful, because the
natural reaction when reading it is to wonder what the significance of
using < rather than != is, when in fact there is no significance to
it.

-- Richard

 

[Coos Haak]

Op 21 Jun 2007 23:24:38 GMT schreef Richard Tobin:

while ((ch = getchar()) != EOF)
Consider signed chars and a char with value less than EOF ;-)

getchar() returns either EOF or the character "as an unsigned char
converted to an int", so even if the character is negative as a signed
char, the value returned by getchar() will be positive. Understood.
Since EOF is
negative, the code is correct. It's just unhelpful, because the
natural reaction when reading it is to wonder what the significance of
using < rather than != is, when in fact there is no significance to
it.[/QUOTE]
Agreed.

 

[CBFalconer]

Op Thu, 21 Jun 2007 22:17:43 +0200 schreef Army1987:

while ((ch = getchar()) != EOF)
Consider signed chars and a char with value less than EOF ;-)

No such thing. Consult the standard definition of getchar().

 

[CBFalconer]

I suppose this is technically correct, modulo the usual question
of what happens if sizeof(int)==1, but it's terrible style. The
value of ch is either a legal character or EOF, so the natural
idiom is

while( (ch=getchar()) != EOF)

Using > instead of != in this case is an insult to the reader.

No it isn't. It is not the usual, but may even improve the actual
code in some instances. The insult is not installing spaces around
the operators, if we must have an insult somewhere

 

[Army1987]

Op Thu, 21 Jun 2007 22:17:43 +0200 schreef Army1987:


while ((ch = getchar()) != EOF)
Consider signed chars and a char with value less than EOF ;-)

Consider reading what the standard says about fgetc(), and hence
about getc(), and hence about getchar().
(Yes, that is a problem on systems where UCHAR_MAX > INT_MAX, but
on these systems there will be an unsigned char which when
converted to int will compare equal to EOF, so even your fix
doesn't help there.)

#include <limits.h>
while ( (ch = getchar()) != EOF
#if UCHAR_MAX > INT_MAX
|| !feof(stdin) && !ferror(stdin)
#endif
)

 

[Flash Gordon]

Dale Henderson wrote, On 21/06/07 16:01:

You should also read question 19.1 in the c FAQ at c-faq.com.
(at least I as I think thats the right question. I couldn't get
c-faq.com to load and used an outdated copy at
http://www.faqs.org/faqs/C-faq/faq/)

http://c-faq.com/ works for me and when possibly it is the link people
should use.