Hello !
My program run correct ( i took it from K&R's book ) but i don't
understand how !!!
I have to input some lines and the program determines the longuest one :

... (beginning not listed)

int inputline ( char tablo [] , int limite )
{
int i=0 , c=0;
for ( i=0; i <= limite-1 && (c=getchar())!=EOF && c!='\n'; ++i )
        {
        printf ("\n%d" , i );
        printf ("\n%d" , c );
        tablo [ i ] = c;
        }
... ( the whole program is not interesting ... )

RESULT of RUN ( I input "azerty" to keyboard and press ENTR key :

SAISIE

azerty

0
97
1
122
2
101
3
114
4
116
5
121

Fin de la saisie : ligne = azerty
Longueur de la ligne saisie = 6

1) How can i specify EOF when i input data with keyboard ???
2) getchar is used to input ONE character, but loop is made 6 times !!!
   ( for each letter of "azerty" )
   ==> did it bufferize my input "azerty" to process it after ENTER
       pressed ?
   It seems to be powerfull, and may be magicfull !!!...

          Thanks for answer. ( Sorry if bad english use ). -)

_______________________________________________________________________
Bruno PONTEPRIMO - SEMA Group
Nanterre - France

Sent via Deja.com http://www.*-*-*.com/
Before you buy.

That depends on the OS. If you redirect input from a file, it seems
obvious that EOF is returned on end-of-file. However, when you input
from the keyboard, you'll need a special key that varies from OS to OS.
Under MS-DOS and derivatives, it's Ctrl-Z; under Unix, IIRC it's Ctrl-D.

getchar() didn't, but your OS most probably did.

Here's another one, which I don't know myself, so I'll ask the gurus:

If it's natural in a certain environment to return a key as soon as it
is pressed, would it be OK for fgets(stdin) to wait for return (well, of
course that part would be OK) but for getchar() to return the key as
soon as it is pressed, or should getchar() also wait for return?
My guess would be that it _is_ OK for getchar() not to wait for return,
but very unusual.

Richard

Once upon a while in a tremendously nice article

This depends on the system you're running. On a unix system the
default key is ^D (which is produced by pressing the Ctrl and the D-key
at the same time) on windooze systems I can't remember the what
it is.

In- and output are normally line buffered. So your assumption is right.

Since getchar waits for data to come in (blocking mode) it will wait
until you press the return key, but than read ONE character and
leave the others that were typed before the return key in the input
buffer. So the loop goes thru once. Now when getchar is called
the second time there is still data remaining in the input buffer
ready to be read, this repeats until the character read is either
EOF or '\n' (which is the return key).

Hope this helps

        Z

--
LISP is worth learning for the profound enlightenment experience you
will have when you finally get it; that experience will make you a
better programmer for the rest of your days.         Eric S. Raymond

That would be Ctrl-ZzzzZZZzzZZZZZ...

--

http://www.eskimo.com/~scs/C-faq/top.html  
The comp.lang.c FAQ

It depends. Try Ctrl+C, Ctrl+D, Ctrl+Z or F6.

The standard library or your operating system did the
buffering, not your code. getchar() simply reads the next character
in the buffer, or if there are no characters in the buffer,
it waits for a whole line to be input.

For pedants:

getchar() will not necessarily wait for a whole line. This depends
on if the stream is "interactive".

Don't worry about it, your English is better than my French.

Bill, failed his modern language GCSE exams.

Once upon a while in a tremendously nice article

Seams like I'm going to forget it in the next five seconds again
amd I'm still doing fine!
:-)

        Z

--
LISP is worth learning for the profound enlightenment experience you
will have when you finally get it; that experience will make you a
better programmer for the rest of your days.         Eric S. Raymond

now there's an unusual complaint... most people are happy it just
"worked".  :-)

<snip output>

the for statement caused the getchar() to be executed repeatedly until
it ran out of input.

the library or OS may have done these things. In fact the OS probably
read the whole the whole line then passed it to your program one
character at a time.

all computer programs are magicfull, this is why they are fun

:-)

--
Software, regardless of the language or OS, is being used to handle
real-world, life-or-death problems. THAT should cause fear, except
that the alternative is for every single emergency to be handled
entirely by humans...

Sent via Deja.com http://www.deja.com/
Before you buy.

I'm not a guru, but the (C99) standard has the following to say about
that:

Clause 7.19.3:
3  When a stream is unbuffered, characters are intended to appear from
the source or at the destination as soon as possible. Otherwise
characters may be accumulated and transmitted to or from the host
environment as a block. ...

I would say that it is *not* ok for getchar() to wait for a newline in
an unbuffered environment.

Bart v Ingen Schenau
--
Remove NOSPAM to mail me directly

It is okay for getchar() to not wait for return. In fact, it's not its job
to wait for return; its job is to return the next available character from
the stream as soon as it is available. The standard library is not required
to delay the delivery of data from the environment to the program.

You find that in UNIX systems, the only reason getchar() appears to block for a
whole line is because the underlying terminal read() system call does so. The
line discipline buffers whole lines of input to give the user an opportunity to
edit the input using a few primitive command characters, like erase to the
beginning of the line, backspace, erase word.  On these systems, you can, prior
to executing the C program, alter the terminal driver behavior such that read()
returns immediately.  Then getchar() will get character at a time input:

        $ stty -icanon min 1 time 0 ; ./c_program ; stty icanon

The fgets() function will still loop until a newline is received, but command
line editing with backspace, word erase or kill will not be supported;
these control characters will just end up in the input.

--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.