471,585 Members | 1,169 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,585 software developers and data experts.

fgets() and extra characters...

Hi,

A book that I'm currently using notes that the fgets() function does
not
return until Return is pressed or an EOF or other error is encountered.

It then at most (in the absence of EOF/error), returns n-1 characters
plus
a appended null character.

Now, my question is:

If during a call to fgets(), (say with n == 64 and stdin), the user
happens
to enter much more than 64 characters, say 128, 256 or something like
that, fgets() would return with first 63 characters and a appended null

character only when the user presses Enter.

What would happen to the other characters? Can I assume that they would

be saved in a libc or OS level buffer and if so, upto what extent?

If fgets() blocks until Enter is pressed, am I correct in the
assumption that
successive calls to fgets() to retrieve the remaining characters would
fail,
since Enter is pressed by the user only once?

I'm confused as to the behaviour fgets() would exhibit under the above
conditions. None of the books or Standard Library documentation seem to

mention it.

Thanks.

Dec 6 '05 #1
11 3435


santosh wrote On 12/06/05 07:21,:
Hi,

A book that I'm currently using notes that the fgets() function does
not
return until Return is pressed or an EOF or other error is encountered.

It then at most (in the absence of EOF/error), returns n-1 characters
plus
a appended null character.

Now, my question is:

If during a call to fgets(), (say with n == 64 and stdin), the user
happens
to enter much more than 64 characters, say 128, 256 or something like
that, fgets() would return with first 63 characters and a appended null

character only when the user presses Enter.

What would happen to the other characters? Can I assume that they would

be saved in a libc or OS level buffer and if so, upto what extent?
The characters not yet read by fgets() remain unread,
and are still on the stream ready for you to read them
with another fgets() or with getc() or whatever you like.

The "up to what extent" answer depends on the operating
system, and on the device from which the stream obtains its
input (remember, input needn't always come from a keyboard).
Consult the O/S documentation for details like the maximum
length of input lines obtained from keyboards, from sockets,
from disk files, ...
If fgets() blocks until Enter is pressed, am I correct in the
assumption that
successive calls to fgets() to retrieve the remaining characters would
fail,
since Enter is pressed by the user only once?
fgets() does not block until Enter is pressed; fgets
just keeps on reading until it receives a newline, fills
the buffer, or encounters end-of-file or error. fgets()
is completely unaware of Enter or of any other key -- or
of mice, light-pens, voice-activated input devices, you
name it. Management of all such devices is the job of
the operating system, which will deliver input characters
to fgets() when it feels like doing so. Again, consult
the O/S documentation.
I'm confused as to the behaviour fgets() would exhibit under the above
conditions. None of the books or Standard Library documentation seem to

mention it.


I hope your confusion is less than it was.

--
Er*********@sun.com

Dec 6 '05 #2
santosh wrote:

Hi,

A book that I'm currently using notes that the fgets() function does
not
return until Return is pressed or an EOF or other error is encountered.

It then at most (in the absence of EOF/error), returns n-1 characters
plus
a appended null character.

Now, my question is:

If during a call to fgets(), (say with n == 64 and stdin), the user
happens
to enter much more than 64 characters, say 128, 256 or something like
that, fgets() would return with first 63 characters and a appended null

character only when the user presses Enter.

What would happen to the other characters? Can I assume that they would

be saved in a libc or OS level buffer and if so, upto what extent?

If fgets() blocks until Enter is pressed, am I correct in the
assumption that
successive calls to fgets() to retrieve the remaining characters would
fail,
since Enter is pressed by the user only once?

I'm confused as to the behaviour fgets() would exhibit under the above
conditions.
None of the books or Standard Library documentation seem to

mention it.


The OK_input function in this post:
http://groups.google.com/group/comp....3d442eaf6cc380
was the last time that I wrote anything with fgets.
It was intended to give reasonable responses
to two kittens fighting on the keyboard.

Now I use this method:
http://groups.google.com/group/comp....bbc52f5be7f3be
If rc equals 0, that means that a zero length string
was entered and the array will contain garbage.

The one caveat, is that if the string length
excedes the LENGTH macro,
then the extra characters just get eaten.

It's good for text files too:
http://groups.google.com/group/comp....e8b7bb11a2c6b8

--
pete
Dec 6 '05 #3
santosh a écrit :
Now, my question is:

If during a call to fgets(), (say with n == 64 and stdin), the user
happens
to enter much more than 64 characters, say 128, 256 or something like
that, fgets() would return with first 63 characters and a appended null
character only when the user presses Enter.
Correct.

What would happen to the other characters? Can I assume that they would
be saved in a libc or OS level buffer and if so, upto what extent?
They are stored somewhere, and can be read by the next call of any input
function like fgets() or fgetc() without any wait (unlesse a '\n' is
read, that denotes that the entire line has finally been read.

Just try it.
If fgets() blocks until Enter is pressed, am I correct in the
assumption that
successive calls to fgets() to retrieve the remaining characters would
fail,
since Enter is pressed by the user only once?

I'm confused as to the behaviour fgets() would exhibit under the above
conditions. None of the books or Standard Library documentation seem to

mention it.


Actually it's well explained about fgetc() in the K&R. The input
functions are based on the fgetc() functions.

--
A+

Emmanuel Delahaye
Dec 6 '05 #4

"pete" <pf*****@mindspring.com> wrote in message
news:43***********@mindspring.com...
santosh wrote:

Hi,

A book that I'm currently using notes that the fgets() function does
not
return until Return is pressed or an EOF or other error is encountered.

It then at most (in the absence of EOF/error), returns n-1 characters
plus
a appended null character.

Now, my question is:

If during a call to fgets(), (say with n == 64 and stdin), the user
happens
to enter much more than 64 characters, say 128, 256 or something like
that, fgets() would return with first 63 characters and a appended null

character only when the user presses Enter.

What would happen to the other characters? Can I assume that they would

be saved in a libc or OS level buffer and if so, upto what extent?

If fgets() blocks until Enter is pressed, am I correct in the
assumption that
successive calls to fgets() to retrieve the remaining characters would
fail,
since Enter is pressed by the user only once?

I'm confused as to the behaviour fgets() would exhibit under the above
conditions.
None of the books or Standard Library documentation seem to

mention it.


The OK_input function in this post:
http://groups.google.com/group/comp....3d442eaf6cc380
was the last time that I wrote anything with fgets.
It was intended to give reasonable responses
to two kittens fighting on the keyboard.

Now I use this method:
http://groups.google.com/group/comp....bbc52f5be7f3be
If rc equals 0, that means that a zero length string
was entered and the array will contain garbage.

The one caveat, is that if the string length
excedes the LENGTH macro,
then the extra characters just get eaten.

It's good for text files too:
http://groups.google.com/group/comp....e8b7bb11a2c6b8


Disclaimer: I'm kinda blind to this 'sort of problem', as - like a lot of
folk(I truly suspect) - since I [can almost] remember - I've only asked the
OS to give me the user's input for quite some time now [20+ years or so].

Had a look at your code [very briefly], but, as I'm tired-out right now, I
found myself saying "ok. So I'm dumb. But what's wrong with fgets()?" And
[but I would like to vote: let's just give-up on scanf()]?"

..
Dec 6 '05 #5
pemo wrote:
But what's wrong with fgets()?" And
fgets gives you all the options
to do whatever you want with all of the input,
but it can be complicated to use,
depending on what you want to do.
[but I would like to vote: let's just give-up on scanf()]?"


If you've decided that discarding the end characters
of lines which excede the buffer size is acceptable,
then using fscanf to read lines is very easy.
If not, then use fgets.

--
pete
Dec 7 '05 #6

"pete" <pf*****@mindspring.com> wrote in message
news:43***********@mindspring.com...
pemo wrote: <snip>
If you've decided that discarding the end characters
of lines which excede the buffer size is acceptable,
then using fscanf to read lines is very easy.
If not, then use fgets.


Sorry, don't get that - it sounds like it ought to read

"If you've decided that discarding the end characters
of lines which excede the buffer size is acceptable,
then using fgets to read lines is very easy.
If not, then use fscanf.

Presumably using fscanf with stdin isn't recommended for buffer overrun
reasons?

Dec 7 '05 #7
santosh wrote:
Hi,

A book that I'm currently using notes that the fgets() function does not
return until Return is pressed or an EOF or other error is encountered.

<snip>

Thanks again to all of you.

I've found through experimentation that fgets() in conjunction with
feof(),
ferror() and clearerr() is as robust as it can get for input from
stdin.

The only 'little issue' is if there happens to be a EOF character
amidst
the normal input, all characters entered after the EOF seem to be
lost...

Dec 7 '05 #8
In article <11*********************@g14g2000cwa.googlegroups. com>,
santosh <sa*********@gmail.com> wrote:
The only 'little issue' is if there happens to be a EOF character
amidst the normal input, all characters entered after the EOF seem to
be lost...


Different operating systems have different ideas about end-of-file, so
you need to find out about the system you are using and probably can't
solve your "little issue" in completely portable C.

For example:

In unix, there's something you can type on the keyboard that indicates
the end of the input. Usually it's control-D. But this doesn't
involve any "end-of-file character" being sent to the program, it
just causes the read to return and afterwards feof() will be true.
Calling clearerr() will let you read more characters. You can send
a control-D character without any implication of end-of-file by
using some escape character.

Similarly, unix files don't have any end-of-file character at the end;
the file's length is stored with it so there's no need for such a
thing.

I believe that Microsoft Windows behaves differently, marking the end
of the file by having a control-Z character in the stream. This is a
problem if that character can actually occur in the data. Opening the
file in binary mode may help, but may also have other implications.

-- Richard
Dec 7 '05 #9
Richard Tobin wrote:
In article <11*********************@g14g2000cwa.googlegroups. com>,
santosh <sa*********@gmail.com> wrote:

The only 'little issue' is if there happens to be a EOF character
amidst the normal input, all characters entered after the EOF seem to
be lost...

Different operating systems have different ideas about end-of-file, so
you need to find out about the system you are using and probably can't
solve your "little issue" in completely portable C.

For example:

In unix, there's something you can type on the keyboard that indicates
the end of the input. Usually it's control-D. But this doesn't
involve any "end-of-file character" being sent to the program, it
just causes the read to return and afterwards feof() will be true.
Calling clearerr() will let you read more characters. You can send
a control-D character without any implication of end-of-file by
using some escape character.

Similarly, unix files don't have any end-of-file character at the end;
the file's length is stored with it so there's no need for such a
thing.

I believe that Microsoft Windows behaves differently, marking the end
of the file by having a control-Z character in the stream. This is a
problem if that character can actually occur in the data. Opening the
file in binary mode may help, but may also have other implications.


Microsoft inherited ^Z from CP/M. The CP/M directory defined a file's
size in 128-byte unit records. Fine for binary files but not for text.
If you would concatenate one text file to another, you had to know
precisely where the first ended. Hence the eof character, ^Z.

Because Microsoft inherited also lots of files from CP/M and because
backward compatibility was important, MS accommodates (to this day) the
^Z in text files. I don't know of any MS file system that actually
requires it.

Note that if you open a MS text file in binary mode you will see not
only any 0x1a (^Z) character but also the 0x0d (^M) carriage return just
before the end of each line.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Dec 7 '05 #10
pemo wrote:
"pete" <pf*****@mindspring.com> wrote in message
news:43***********@mindspring.com...
pemo wrote: <snip>
If you've decided that discarding the end characters
of lines which excede the buffer size is acceptable,
then using fscanf to read lines is very easy.
If not, then use fgets.


Sorry, don't get that - it sounds like it ought to read

"If you've decided that discarding the end characters
of lines which excede the buffer size is acceptable,
then using fgets to read lines is very easy.
If not, then use fscanf.


No, I think Pete's post reads correctly.
Presumably using fscanf with stdin isn't recommended for buffer overrun
reasons?


No, it's generally not recommended because it can be hard to use,
however if used correctly there is no risk of buffer overflows.

In this particular case, I believe you could get fscanf to read a
maximum of N characters on a line then discard everything up to and
including the new line character. With fgets on the other hand
everything after what fitted in the buffer will still be there and you
will have to read it.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Dec 7 '05 #11
pemo wrote:

"pete" <pf*****@mindspring.com> wrote in message
news:43***********@mindspring.com...
pemo wrote:

<snip>

If you've decided that discarding the end characters
of lines which excede the buffer size is acceptable,
then using fscanf to read lines is very easy.
If not, then use fgets.


Sorry, don't get that


Run the program type_.c on a text file.

http://groups.google.com/group/comp....e8b7bb11a2c6b8

Then
change the value of the LINE_LEN macro
to something smaller than the text file's longest line,
if you want to see how that goes,
unless it already is that small.

--
pete
Dec 8 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

35 posts views Thread by David Mathog | last post: by
42 posts views Thread by mellyshum123 | last post: by
20 posts views Thread by Xavoux | last post: by
285 posts views Thread by Sheth Raxit | last post: by
26 posts views Thread by Bill Cunningham | last post: by
reply views Thread by XIAOLAOHU | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.