The behaviour of getchar()

[Emmanuel Delahaye]

Hi there,

It is commonly accepted that a call to the getchar() function suspends the
execution of the current program. I have not found any description of this
behaviour in the standard (I may have missed it).

I was wondering wether it was just a 'common' behaviour of most systems, and
wether the hit of the ENTER key was mandatory.

Thanks for having read me.

 

[Joona I Palaste]

Hi there,

It is commonly accepted that a call to the getchar() function suspends the
execution of the current program. I have not found any description of this
behaviour in the standard (I may have missed it).

I was wondering wether it was just a 'common' behaviour of most systems, and
wether the hit of the ENTER key was mandatory.

Thanks for having read me.

I think that the standard only says that getchar() suspends execution
until a character appears on stdin. Where that character came to stdin
from is none of C's business. Specifically, C knows nothing whatsoever
of "ENTER keys". It's an OS-specific buffering mechanism that happens
before C sees any hint of the characters.
Try redirecting stdin from a file that contains no EOL (End Of Line)
markers and you'll see getchar() works just fine without reading any
"ENTER keys".

 

[pete]

Hi there,

It is commonly accepted that a call to the getchar()
function suspends the execution of the current program.

All function calls do that.

N869
6.2.4 Storage durations of objects
[#4]
Entering an enclosed block or calling a function suspends,
but does not end, execution of the current block.

 

[Malcolm]

It is commonly accepted that a call to the getchar() function suspends >

the execution of the current program. I have not found any

description of this behaviour in the standard (I may have missed it).

The standard is a formal specification of a conforming implementation, it is
not designed to teach C.
In this case every implementation you will come across whilst learning C
will have a keyboard, a line buffer, and some facilities to edit the line
before entering it. Obviously this entails suspending execution until the
user enters the line.
However the standard doesn't force the computer to work that way - in fact
it is not uncommon to redirect a file to stdin and run a program on
automatic input.

 

[Peter Nilsson]

Hi there,

It is commonly accepted that a call to the getchar() function suspends the
execution of the current program. I have not found any description of this
behaviour in the standard (I may have missed it).

I was wondering wether it was just a 'common' behaviour of most systems,
and wether the hit of the ENTER key was mandatory.

7.19.3 deals with the buffering of stdin, but it's usually the host
environment that makes the real choice. Turning line buffering off (host
side) is not possible in ISO C.

See FAQ 19.1

 

[Richard Bos]

It is commonly accepted that a call to the getchar() function suspends the
execution of the current program. I have not found any description of this
behaviour in the standard (I may have missed it).

I was wondering wether it was just a 'common' behaviour of most systems, and
wether the hit of the ENTER key was mandatory.

No, it isn't. Consider, for example, this command line:

c_program_using_getchar <input_file

Richard

 

[Dan Pop]

It is commonly accepted that a call to the getchar() function suspends the
execution of the current program. I have not found any description of this
behaviour in the standard (I may have missed it).

A call to *any* standard library function suspends the execution of
the current program until the function returns. Why would a call to
getchar be any different?

I was wondering wether it was just a 'common' behaviour of most systems,

Would it make any sense for the program to continue its execution *before*
getchar returns?

and wether the hit of the ENTER key was mandatory.

It's provided as a convenience, so that you have a chance to correct your
input before pressing the Enter key, if you make a typo and notice it
before it's too late. On some systems this behaviour can be altered.
The following program shows how to turn getchar into the MSDOS getche on
a Unix system (assuming stdin was not redirected):

#include <stdio.h>
#include <stdlib.h>

int main()
{
int c;
printf("Press an alphanumeric key...\n");
system("stty raw");
c = getchar();
system("stty -raw");
printf("\nBye.\n");
return 0;
}

You can even emulate the MSDOS getch, by adding one more option to the
stty command. There a better ways of doing that in Unix, but this one
is based exclusively on standard library function calls ;-)

Dan

 

[Dan Pop]

No, it isn't. Consider, for example, this command line:

c_program_using_getchar <input_file

What about it? Does the standard say anything about "<input_file" when
used as a program's first parameter?

Dan

 

[Joona I Palaste]

What about it? Does the standard say anything about "<input_file" when
used as a program's first parameter?

Am I too pedantic for understanding exactly what Dan Pop means here?

 

[Emmanuel Delahaye]

A call to *any* standard library function suspends the execution of
the current program until the function returns. Why would a call to
getchar be any different?

I meant 'until some <enter> key is pressed". Sorry, but it sounded obvious to
me...

It's provided as a convenience, so that you have a chance to correct
your input before pressing the Enter key, if you make a typo and notice
it before it's too late. On some systems this behaviour can be altered.
The following program shows how to turn getchar into the MSDOS getche on
a Unix system (assuming stdin was not redirected):

#include <stdio.h>
#include <stdlib.h>

int main()
{
int c;
printf("Press an alphanumeric key...\n");
system("stty raw");
c = getchar();
system("stty -raw");
printf("\nBye.\n");
return 0;
}

You can even emulate the MSDOS getch, by adding one more option to the
stty command. There a better ways of doing that in Unix, but this one
is based exclusively on standard library function calls ;-)

Thanks. It's crystal clear.

 

[Dan Pop]

I meant 'until some <enter> key is pressed". Sorry, but it sounded obvious to
me...

We're reading your text, not your mind...

Dan

 

[Eric Sosman]

A call to *any* standard library function suspends the execution of
the current program until the function returns. Why would a call to
getchar be any different?

ITYM "almost any" instead of "*any*". exit() and _Exit()
come to mind as counter-examples, and one could make a case
for abort() and raise() in the proper circumstances. longjmp()
does such violence to the ordinary discipline of function calls
that the word "returns" doesn't seem adequate.

 

[Dan Pop]

ITYM "almost any" instead of "*any*". exit() and _Exit()
come to mind as counter-examples,

Nope, they aren't. Since they don't return, the program execution is
never resumed.

and one could make a case
for abort() and raise() in the proper circumstances.

???

abort() is in the same category as exit() and _Exit().

2 The raise function carries out the actions described in 7.14.1.1
for the signal sig. If a signal handler is called, the raise
function shall not return until after the signal handler does.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Returns

3 The raise function returns zero if successful, nonzero if
unsuccessful.

longjmp()
does such violence to the ordinary discipline of function calls
that the word "returns" doesn't seem adequate.

Yet, the program execution is not resumed until the completion of the
function's execution (if you don't like the word "return").

4 After longjmp is completed, program execution continues as if
^^^^^^^^^

So, what exactly was your point, if any?

Dan