Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > getchar

Reply
Thread Tools

getchar

 
 
john
Guest
Posts: n/a
 
      05-06-2006
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?
 
Reply With Quote
 
 
 
 
Denis Kasak
Guest
Posts: n/a
 
      05-06-2006
john wrote:
> 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
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      05-06-2006
john wrote:
> 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().

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)lid
 
Reply With Quote
 
DeAtHaLiVe
Guest
Posts: n/a
 
      05-06-2006
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))

 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      05-06-2006
In article <(E-Mail Removed)>,
Eric Sosman <(E-Mail Removed)> wrote:

> 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!
--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes
 
Reply With Quote
 
Jordan Abel
Guest
Posts: n/a
 
      05-06-2006
On 2006-05-06, Eric Sosman <(E-Mail Removed)> wrote:
> john wrote:
>> 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.)


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

>
> 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().
>

 
Reply With Quote
 
Michael Mair
Guest
Posts: n/a
 
      05-06-2006
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>

DeAtHaLiVe schrieb:
> 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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
 
Reply With Quote
 
Michael Mair
Guest
Posts: n/a
 
      05-06-2006
Jordan Abel schrieb:
> On 2006-05-06, Eric Sosman <(E-Mail Removed)> wrote:
>
>>john wrote:
>>
>>>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.)

>
> 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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      05-06-2006
Walter Roberson wrote:

> In article <(E-Mail Removed)>,
> Eric Sosman <(E-Mail Removed)> wrote:
>
>
>> 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!


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!)

--
Eric Sosman
(E-Mail Removed)lid
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      05-07-2006
DeAtHaLiVe wrote:
>
> 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/>


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
scanf/getchar sequence problem clusardi2k@aol.com C++ 21 04-20-2005 09:50 AM
getchar vs. cin Kristo C++ 1 03-24-2005 08:25 PM
Use of getchar Cam C++ 3 05-30-2004 11:39 AM
Re: getchar returns int, assign to array of char? Ben Fitzgerald C Programming 1 06-28-2003 02:24 AM
Re: getchar returns int, assign to array of char? Ben Fitzgerald C Programming 9 06-27-2003 07:04 PM



Advertisments