By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,678 Members | 1,144 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,678 IT Pros & Developers. It's quick & easy.

what'd the difference between STDIN and Keyboard buffer ?

P: n/a
What's the difference between STDIN and Keyboard buffer ?

when i get char through scanf, i type in some characters and press
enter,
then, where do the characters go ? to STDIN or Keyboard buffer ? are
they same ?

thanks ^^
Nov 13 '05 #1
Share this Question
Share on Google+
23 Replies


P: n/a

"herrcho" <he*********@kornet.net> wrote in message
news:bk**********@news1.kornet.net...
What's the difference between STDIN and Keyboard buffer ?
As to the standard C language, nothing. Neither has
anything to do with it.

However, 'stdin' (note the lower case) is the identifier
that the C standard library uses to designate the 'standard
input stream' of a program.

C has no support for any particular hardware devices,
be they keyboards, meeces, video displays, or whatever.
All i/o is abstracted as 'streams of characters'.

when i get char through scanf, i type in some characters and press
enter,
then, where do the characters go ?
They're stored in the object whose address you must
have supplied as an argument to 'scanf()'? What
happens between the time the user presses the keys
and the point where your data is present in your
varaible depends upon your platform, and is not
addressed by the C language, which is platform
independent.

to STDIN or Keyboard buffer ? are
they same ?


See above.

BTW what is the motivation for your questions?

-Mike
Nov 13 '05 #2

P: n/a
Mike Wahler writes:
to STDIN or Keyboard buffer ? are
they same ?


See above.

BTW what is the motivation for your questions?


Sounds to me like another one of those guys that just like to *know* things.
Perhaps he realizes how much this irritates you.
Nov 13 '05 #3

P: n/a
Mike Wahler wrote:
C has no support for any particular hardware devices,
be they keyboards, meeces, video displays, or whatever.
All i/o is abstracted as 'streams of characters'.


What the h*** are "meeces"? Is that the plural for mice ;) (which in turn
is plural for mouse)?

--
Martijn
http://www.sereneconcepts.nl
Nov 13 '05 #4

P: n/a
Mike Wahler wrote:

"herrcho" <he*********@kornet.net> wrote in message
news:bk**********@news1.kornet.net...
What's the difference between STDIN and Keyboard buffer ?


As to the standard C language, nothing. Neither has
anything to do with it.

However, 'stdin' (note the lower case) is the identifier
that the C standard library uses to designate the 'standard
input stream' of a program.


It's a bit of sloppiness on the part of both K&R2 and the standard,
to use stdin that way.
stdin is described as being an expression of type pointer to FILE.
FILE is an object type capable of recording all the information
needed to control a stream.
The object that stdin points to,
is associated with the standard input stream.

--
pete
Nov 13 '05 #5

P: n/a
In <bk**********@news1.kornet.net> "herrcho" <he*********@kornet.net> writes:
What's the difference between STDIN and Keyboard buffer ?

when i get char through scanf, i type in some characters and press
enter,
then, where do the characters go ? to STDIN or Keyboard buffer ? are
they same ?


Your question makes sense only if stdin is connected to an interactive
terminal. Although this is quite common, keep in mind that it is not
necessarily the case, on many implementations stdin can be connected
to a file or some other kind of device.

To understand the difference between stdin and keyboard buffer, you
must realise that stdin is a C library concept and it is implemented at
that level, while the keyboard buffer is an operating system concept (and
implemented at that level).

So, the characters you type go into the keyboard buffer (you may type them
even at a time when the program doesn't wait for stdin input, so something
must take care of them). When your program needs input from stdin, an
input function from the standard library implementation asks the OS to
deliver the contents of the keyboard buffer as soon as it may be made
available to the program. At that point, the characters get moved from
the keyboard buffer into stdin's buffer.

Of course, this is not the only scenario possible in practice and things
are also affected by the buffering mode of stdin (line-buffered or
non-buffered) and by the buffering mode of the terminal driver of your OS
(characters may be delivered to the application only when a newline is
already in the keyboard buffer or at any time). But you get a general
idea about the difference between the two.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #6

P: n/a
pete writes:
It's a bit of sloppiness on the part of both K&R2 and the standard,
to use stdin that way.
stdin is described as being an expression of type pointer to FILE.
FILE is an object type capable of recording all the information
needed to control a stream.
The object that stdin points to,
is associated with the standard input stream.


I don't know what that means so I won't argue. (I don't know what "use
stdin that way" means. What is 'that'?) My answer would be that the
keyboard buffer is a useful *hardware* thing, even though the phrase itself
and the messy details are handled by software. God did not ordain that
there be a keyboard buffer. A good way to partition the workload and
minimize the number of hardware interrupts is to provide the rudiments
needed to allow keyboard buffers. If you look at a DOS era machine, you
already have the beginnings of multi-tasking: input and editing are distinct
from computing.

stdin, OTOH, is *strictly* a software concept. I am not a historian but my
first guess is that it goes back to the standard '5', or whatever, used in
Fortran I/O. Which used to be spelled FORTRAN.
Nov 13 '05 #7

P: n/a

"Martijn" <su*********************@hotNOFILTERmail.com> wrote in message
news:3f***********************@news.xs4all.nl...
Mike Wahler wrote:
C has no support for any particular hardware devices,
be they keyboards, meeces, video displays, or whatever.
All i/o is abstracted as 'streams of characters'.
What the h*** are "meeces"?


Me sez I can use poetic license. :-)

" Is that the plural for mice ;) (which in turn is plural for mouse)?


Something like that. Just having a bit of fun. :-)

I suppose being from NL you don't know the reference::
The old U.S. cartoon show from the sixties, "Tom and
Jerry", about two mice and their nemesis, the cat
that frequently says after being outsmarted:
"I hate those meeces to pieces!" :-)

-Mike

Nov 13 '05 #8

P: n/a
In <bk************@ID-179017.news.uni-berlin.de> "osmium" <r1********@comcast.net> writes:
stdin, OTOH, is *strictly* a software concept. I am not a historian but my
first guess is that it goes back to the standard '5', or whatever, used in
Fortran I/O. Which used to be spelled FORTRAN.


It's actually '*' in FORTRAN and it stands for both "standard input"
and "standard output", but I'm not sure at what point it became a standard
FORTRAN feature (it is specified by F77, but I used F-IV compilers that
didn't support it).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #9

P: n/a
Mike Wahler wrote:
I suppose being from NL you don't know the reference::
The old U.S. cartoon show from the sixties, "Tom and
Jerry", about two mice and their nemesis, the cat
that frequently says after being outsmarted:
"I hate those meeces to pieces!" :-)


<cartoon pedantry>

Actually, that was from the adventures of Trixie and Dixie (the meeces)
and Jinx the cat. In classic Tom & Jerry, neither ever spoke.

</cartoon pedantry>


Brian Rodenborn
Nov 13 '05 #10

P: n/a

"Default User" <fi********@company.com> wrote in message
news:3F***************@company.com...
Mike Wahler wrote:
I suppose being from NL you don't know the reference::
The old U.S. cartoon show from the sixties, "Tom and
Jerry", about two mice and their nemesis, the cat
that frequently says after being outsmarted:
"I hate those meeces to pieces!" :-)


<cartoon pedantry>

Actually, that was from the adventures of Trixie and Dixie (the meeces)
and Jinx the cat. In classic Tom & Jerry, neither ever spoke.

</cartoon pedantry>


Oh, yeah, you're right.

I guess this stuff dates me pretty well, and exposes my
faulty memory. Mental segfault. :-)

-Mike
Nov 13 '05 #11

P: n/a
Default User wrote:
Actually, that was from the adventures of Trixie and Dixie (the meeces)
and Jinx the cat.
To be boring for a moment re "meeces": the mouse's inventor, Doug Engelbart
(who is, perhaps, the only one we might expect to have a definitive
opinion), says he "doesn't know" the plural of "mouse" (in the computer
peripheral sense), which leaves us free to use whatever name we like best.

Microsoft recommend "mouse devices", but of course everybody ignores them.
IME the mindshare seems to be split between "mice", "mouses", and "meeces"
(in descending order of popularity).
In classic Tom & Jerry, neither ever spoke.


This is an easy statement to justify, since any cartoon in which either Tom
or Jerry speaks is clearly /not/ a classic. :-)

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #12

P: n/a
Richard Heathfield wrote:
Microsoft recommend "mouse devices", but of course everybody ignores them.
IME the mindshare seems to be split between "mice", "mouses", and "meeces"
(in descending order of popularity).


I prefer "mouses" myself, but "mice" seems popular around the office.
In classic Tom & Jerry, neither ever spoke.


This is an easy statement to justify, since any cartoon in which either Tom
or Jerry speaks is clearly /not/ a classic. :-)

By classic I meant created by MGM for theater(re) showings. Only some
later made-for-TV T&Js had speaking parts (and much reduced violence
levels).


Brian Rodenborn
Nov 13 '05 #13

P: n/a
osmium wrote:

pete writes:
It's a bit of sloppiness on the part of both K&R2 and the standard,
to use stdin that way.
stdin is described as being an expression of type pointer to FILE.
FILE is an object type capable of recording all the information
needed to control a stream.
The object that stdin points to,
is associated with the standard input stream.


I don't know what that means so I won't argue.
(I don't know what "use stdin that way" means. What is 'that'?)


"use the word 'stdin', that way"

It means that they call the standard output stream 'stdin'
even though they define 'stdin' as something else.

--
pete
Nov 13 '05 #14

P: n/a
pete wrote:

osmium wrote:

pete writes:
It's a bit of sloppiness on the part of both K&R2 and the standard,
to use stdin that way.
stdin is described as being an expression of type pointer to FILE.
FILE is an object type capable of recording all the information
needed to control a stream.
The object that stdin points to,
is associated with the standard input stream.
I don't know what that means so I won't argue.
(I don't know what "use stdin that way" means. What is 'that'?)


"use the word 'stdin', that way"

It means that they call the standard output stream 'stdin'


It means that they call the standard input stream 'stdin'
even though they define 'stdin' as something else.


--
pete
Nov 13 '05 #15

P: n/a

"pete" <pf*****@mindspring.com> wrote in message
news:3F***********@mindspring.com...
osmium wrote:

pete writes:
It's a bit of sloppiness on the part of both K&R2 and the standard,
to use stdin that way.
stdin is described as being an expression of type pointer to FILE.
FILE is an object type capable of recording all the information
needed to control a stream.
The object that stdin points to,
is associated with the standard input stream.
I don't know what that means so I won't argue.
(I don't know what "use stdin that way" means. What is 'that'?)


"use the word 'stdin', that way"

It means that they call the standard output stream 'stdin'


Really, my copy says it's called 'stdout'. :-)
even though they define 'stdin' as something else.


What something else? The standard input stream?

-Mike
Nov 13 '05 #16

P: n/a
Mike Wahler wrote:
"pete" <pf*****@mindspring.com> wrote in message
news:3F***********@mindspring.com...
osmium wrote:
pete writes: > stdin is described as being
> an expression of type pointer to FILE.
> FILE is an object type capable of recording all the information
> needed to control a stream.
> The object that stdin points to,
> is associated with the standard input stream.
even though they define 'stdin' as something else.


What something else? The standard input stream?


I wrote some of that post correctly.
Reread the part that I left quoted above.

Do you think that an expression of type pointer to FILE,
is a stream ?
Nov 13 '05 #17

P: n/a

"pete" <pf*****@mindspring.com> wrote in message
news:3F***********@mindspring.com...
Mike Wahler wrote:
"pete" <pf*****@mindspring.com> wrote in message
news:3F***********@mindspring.com...
osmium wrote:
> pete writes: > stdin is described as being
> > an expression of type pointer to FILE.
> > FILE is an object type capable of recording all the information
> > needed to control a stream.
> > The object that stdin points to,
> > is associated with the standard input stream. even though they define 'stdin' as something else.


What something else? The standard input stream?


I wrote some of that post correctly.
Reread the part that I left quoted above.

Do you think that an expression of type pointer to FILE,
is a stream ?


I think it's a pointer to a stream, with the stream
abstraction being implemented with type 'FILE'.

-Mike
Nov 13 '05 #18

P: n/a
Mike Wahler wrote:

"pete" <pf*****@mindspring.com> wrote in message
news:3F***********@mindspring.com...
Mike Wahler wrote:
"pete" <pf*****@mindspring.com> wrote in message
news:3F***********@mindspring.com...
> osmium wrote:
> > pete writes:

> > > stdin is described as being
> > > an expression of type pointer to FILE.
> > > FILE is an object type capable of recording all the information
> > > needed to control a stream.
> > > The object that stdin points to,
> > > is associated with the standard input stream.

> even though they define 'stdin' as something else.

What something else? The standard input stream?


I wrote some of that post correctly.
Reread the part that I left quoted above.

Do you think that an expression of type pointer to FILE,
is a stream ?


I think it's a pointer to a stream,
with the stream abstraction
being implemented with type 'FILE'.


stdin is a pointer to an object.

If stdin were a pointer to a stream, as you say it is,
then stdin still wouldn't be a stream.

--
pete
Nov 13 '05 #19

P: n/a
"pete" <pf*****@mindspring.com> wrote in message
news:3F***********@mindspring.com...
Mike Wahler wrote:

"pete" <pf*****@mindspring.com> wrote in message
news:3F***********@mindspring.com...
Mike Wahler wrote:
> "pete" <pf*****@mindspring.com> wrote in message
> news:3F***********@mindspring.com...
> > osmium wrote:
> > > pete writes:

> > > > stdin is described as being
> > > > an expression of type pointer to FILE.
> > > > FILE is an object type capable of recording all the information > > > > needed to control a stream.
> > > > The object that stdin points to,
> > > > is associated with the standard input stream.

> > even though they define 'stdin' as something else.
>
> What something else? The standard input stream?

I wrote some of that post correctly.
Reread the part that I left quoted above.

Do you think that an expression of type pointer to FILE,
is a stream ?
I think it's a pointer to a stream,
with the stream abstraction
being implemented with type 'FILE'.


stdin is a pointer to an object.


... which represents a stream.
If stdin were a pointer to a stream,
It's a macro that expands to a pointer to 'FILE'
as you say it is,
then stdin still wouldn't be a stream.


I didn't say that stdin is or is not a stream.
I would say that the expression 'stdin' *denotes*
a stream, which led to my 'loose' term 'pointer
to a stream'.
7.19 Input/output <stdio.h>

7.19.1 Introduction

1 The header <stdio.h> declares three types, several macros,
and many functions for performing input and output.

2 The types declared are ...

[...]

FILE

which is an object type capable of recording all the
information needed to control a stream, including its
file position indicator, a pointer to its associated
buffer (if any), an error indicator that records whether
a read/write error has occurred, and an end-of-file
indicator that records whether the end of the file has
been reached

[...]

3 The macros are ...

[...]

stderr
stdin
stdout

which are expressions of type "pointer to FILE" that
point to the FILE objects associated, respectively,
with the standard error, input, and output streams.

I don't think calling a 'FILE' an abstraction of a stream
is inaccurate.

But I suppose we're only mincing words here. :-)

-Mike
Nov 13 '05 #20

P: n/a
Mike Wahler wrote:

"pete" <pf*****@mindspring.com> wrote in message
news:3F***********@mindspring.com...
Mike Wahler wrote:

"pete" <pf*****@mindspring.com> wrote in message
news:3F***********@mindspring.com...
> Mike Wahler wrote: > > > even though they define 'stdin' as something else.
> >
> > What something else? The standard input stream?
At the point in the thread when you wrote that,
were you aware of the part of the standard which you quoted below,
where stdin is defined as a pointer expression ?
> I wrote some of that post correctly.
> Reread the part that I left quoted above.
>
> Do you think that an expression of type pointer to FILE,
> is a stream ?

I think it's a pointer to a stream,
with the stream abstraction
being implemented with type 'FILE'.
stdin is a pointer to an object.


.. which represents a stream.
If stdin were a pointer to a stream,


It's a macro that expands to a pointer to 'FILE'


It doesn't have to be a macro.
as you say it is,
then stdin still wouldn't be a stream.


I didn't say that stdin is or is not a stream.


Who said you did?
I would say that the expression 'stdin' *denotes* a stream,
That's one example of loose terminology.
Your quoted standard text would look pretty funny
if the standard were consistent with that usage:
stderr
stdin
stdout

which are expressions of type "pointer to FILE" that
point to the FILE objects associated, respectively,
with stderr, stdin, and stdout.

which led to my 'loose' term 'pointer to a stream'.
Loose terminology in the C standard was my point.
The meaning of stdin,
is the topic of the subject line of this thread.
7.19 Input/output <stdio.h>

7.19.1 Introduction

1 The header <stdio.h> declares three types, several macros,
and many functions for performing input and output.

2 The types declared are ...

[...]

FILE

which is an object type capable of recording all the
information needed to control a stream, including its
file position indicator, a pointer to its associated
buffer (if any), an error indicator that records whether
a read/write error has occurred, and an end-of-file
indicator that records whether the end of the file has
been reached

[...]

3 The macros are ...

[...]

stderr
stdin
stdout

which are expressions of type "pointer to FILE" that
point to the FILE objects associated, respectively,
with the standard error, input, and output streams.
Now there,
the standard is plainly describing the relationship
between stdin and the standard input stream,
and they are two different things.
I don't think calling a 'FILE' an abstraction of a stream
is inaccurate.
If you want to call that "an abstraction",
(defining two seperate things and then calling one of them
by the name of the other)
then abstraction doesn't belong in the standard,
and there is no other abstraction like that
anywhere else in the standard.
But I suppose we're only mincing words here. :-)


My answer to OP's question in the subject line is:
A keyboard is one kind file commonly associated with the
standard input stream.
stdin is a pointer expression, pointing to an object
associated with the standard input stream.

--
pete
Nov 13 '05 #21

P: n/a
In article <3F***********@mindspring.com>
pete <pf*****@mindspring.com> wrote (in part):
It [stdin] doesn't have to be a macro.


Actually, it *does* have to be a macro, for no good reason other
than "the standard's wording accidentally says so". You requoted
the text yourself here:
3 The macros are ...
[...]
stderr
stdin
stdout


Because this says "macros", a <stdio.h> that uses:

extern FILE *stdin, *stdout, *stderr;

(as at least one GNU-library header does) must also contain:

#define stdin stdin
#define stdout stdout
#define stderr stderr

simply so that a "compiler conformance testing suite" that uses:

#include <stdio.h>

#ifndef stdin
# error stdin is not a macro
#endif

will not fail.

(Everything else you wrote appears fine to me, and there is no good
REASON for the above as far as I know -- it just happens to be "one
of those things", as they say.)
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 13 '05 #22

P: n/a
Chris Torek wrote:

In article <3F***********@mindspring.com>
pete <pf*****@mindspring.com> wrote (in part):
It [stdin] doesn't have to be a macro.


Actually, it *does* have to be a macro, for no good reason other
than "the standard's wording accidentally says so". You requoted
the text yourself here:
3 The macros are ...
[...]
stderr
stdin
stdout


Because this says "macros", a <stdio.h> that uses:

extern FILE *stdin, *stdout, *stderr;

(as at least one GNU-library header does) must also contain:

#define stdin stdin
#define stdout stdout
#define stderr stderr

simply so that a "compiler conformance testing suite" that uses:

#include <stdio.h>

#ifndef stdin
# error stdin is not a macro
#endif

will not fail.

(Everything else you wrote appears fine to me, and there is no good
REASON for the above as far as I know -- it just happens to be "one
of those things", as they say.)


Thank you.

--
pete
Nov 13 '05 #23

P: n/a
Chris Torek <no****@elf.eng.bsdi.com> wrote:

Actually, it *does* have to be a macro, for no good reason other
than "the standard's wording accidentally says so".


Indeed. There are some other things (most notably errno) that are
allowed to be either macros or identifiers with external linkage, but we
neglected to allow that license for stdin and friends. Like Chris says,
there's no good reason for it, it just never came up.

-Larry Jones

See if we can sell Mom and Dad into slavery for a star cruiser. -- Calvin
Nov 13 '05 #24

This discussion thread is closed

Replies have been disabled for this discussion.