getchar

[john]

What does the standard say about getchar()? Do you have to press
return to "send" the char to the program, or is it implementation
defined? I read in a book that on some systems the function returns
after you just typed the char, thus, it has no input buffer.
Is that correct?

 

[Denis Kasak]

What does the standard say about getchar()? Do you have to press
return to "send" the char to the program, or is it implementation
defined? I read in a book that on some systems the function returns
after you just typed the char, thus, it has no input buffer.
Is that correct?

Correct. Whether line buffering is performed by your terminal is
implementation defined and cannot be changed from within standard C.
However, on most systems, you can switch between line-mode and
character-mode by using implementation specific functions. You should
consult your system's documentation for further information.

-- Denis

 

[Eric Sosman]

What does the standard say about getchar()? Do you have to press
return to "send" the char to the program, or is it implementation
defined? I read in a book that on some systems the function returns
after you just typed the char, thus, it has no input buffer.
Is that correct?

getchar() reads and returns the next character from the
stdin stream, or returns EOF if an I/O error occurs or if there
are no more characters. That's what the Standard says (although
it says so more precisely.)

The stdin stream communicates with some kind of an input
source: keyboard, disk file, socket, joystick, microphone, or
telepathic thingummy. The mechanics of how these various
sources produce their characters are as diverse as the sources
themselves -- but they have nothing to do with stdin per se,
and nothing to do with getchar().

 

[DeAtHaLiVe]

I think you'd better say what operating system and C compiler you have.
I use Bloodshed Dev-C++ on Win32 platform. There after read character
with getchar user has to press enter. If you want just read character
and without enter pressing continue in program, use command getche()
(conio.h library). it has the same use as getchar ;o))

 

[Walter Roberson]

The stdin stream communicates with some kind of an input
source: keyboard, disk file, socket, joystick, microphone, or
telepathic thingummy.

Say, are nasal demons output only, seperate input and output
channels, or bi-directional? Inquiring DS9000 implementers want to know!

 

[Jordan Abel]

getchar() reads and returns the next character from the
stdin stream, or returns EOF if an I/O error occurs or if there
are no more characters. That's what the Standard says (although
it says so more precisely.)

It also says that stdin and stdout are to be line buffered when
connected to an interactive device, and fully buffered otherwise.

 

[Michael Mair]

Please provide sufficient context, either by quoting or by describing
the parts you are answering to.

<OP wants to know whether getchar() has always to "wait" for '\n' or
whether there are implementations where getchar() works unbuffered>

I think you'd better say what operating system and C compiler you have.
I use Bloodshed Dev-C++ on Win32 platform. There after read character
with getchar user has to press enter.

As stated by others, the behaviour of getchar() depends on the
behaviour of stdin. stdin seems to be line-buffered rather than
unbuffered for interactive devices in your case.

If you want just read character
and without enter pressing continue in program, use command getche()
(conio.h library). it has the same use as getchar ;o))

You suggest that the OP uses an implementation specific way of reading
in characters from stdin unbuffered. This may not always be possible
due to external (e.g. hardware) restrictions.

I suggest the use of a macro or function wrapping the implementation
specific part -- this way, you can change the actual way of doing this
"under the hood" without affecting the rest of the program.
In addition, if you have wrapped the input and output parts, you can
even more easily adapt to different implementations. Your programme
itself then calls only "obtainAnswerCharacterFromUser()", for example,
and it does not play a role whether this is typed in via keyboard
followed or not followed by hitting the enter key or chosen from a
display via mouse or pen or ...


Cheers
Michael

 

[Michael Mair]

It also says that stdin and stdout are to be line buffered when
connected to an interactive device, and fully buffered otherwise.

No, at least not in the C89 last public draft, the C99 standard and
N1124: There, I have "fully buffered if and only if it is not 100%
clear that we are not connected to an interactive device" (in my own
words) where the introduction states that the implementation defines
what constitutes an "interactive device".
This means that we have either line buffered or unbuffered stdin.
The only thing I could not find is whether you can portably affect
this behaviour with a setbuf() or setvbuf() as the very first thing
in main() but I have not searched very hard.

Cheers
Michael

 

[Eric Sosman]

Say, are nasal demons output only, seperate input and output
channels, or bi-directional? Inquiring DS9000 implementers want to know!

It should be obvious that nasal demons are no strangers
to input: `fflush(stdin)' ...

(Long ago, comp.lang.c used to teem with descriptions of possible
undefined behaviors. "Demons will fly from your nose" became a sort
of standard, but I think standardization has stifled creativity and
deprived us of much amusement. My favorite U.B. description spoke of
chocolate pudding oozing from the floppy drive. Ah me, they just don't
write 'em like that any more!)

 

[CBFalconer]

I think you'd better say what operating system and C compiler you
have. I use Bloodshed Dev-C++ on Win32 platform. There after read
character with getchar user has to press enter. If you want just
read character and without enter pressing continue in program, use
command getche() (conio.h library). it has the same use as getchar

What, if anything, are you talking about? You have failed to
include context (see my sig below), are referencing non-existent
routines (getche()) and include files (conio.h). Any time an
article needs a reference to the OS and compiler it is
automatically off-topic here, where we discuss the portable C
language, as defined by the various standards.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Kenneth Brody]

Eric Sosman wrote:
[...]

(Long ago, comp.lang.c used to teem with descriptions of possible
undefined behaviors. "Demons will fly from your nose" became a sort
of standard, but I think standardization has stifled creativity and
deprived us of much amusement. My favorite U.B. description spoke of
chocolate pudding oozing from the floppy drive. Ah me, they just don't
write 'em like that any more!)

But if that were the case, then any time someone were to invoke UB in
some code, they would also be invoking UB in the group's response, in
effect causing a meta-UB rip in the time-space continuum.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>