473,320 Members | 2,107 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 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 3624


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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

20
by: TTroy | last post by:
Hello, I have found some peculiar behaviour in the fgets runtime library function for my compiler/OS/platform (Dev C++/XP/P4) - making a C console program (which runs in a CMD.exe shell). The...
35
by: David Mathog | last post by:
Every so often one of my fgets() based programs encounters an input file containing embedded nulls. fgets is happy to read these but the embedded nulls subsequently cause problems elsewhere in...
6
by: AMT2K5 | last post by:
Hello. I have a file (for a school assignment) with the following format and delimiter format. Each record in the file has the following format: 123423454567987,29873,James,Harry,St....
42
by: mellyshum123 | last post by:
I need to read in a comma separated file, and for this I was going to use fgets. I was reading about it at http://www.cplusplus.com/ref/ and I noticed that the document said: "Reads characters...
20
by: Xavoux | last post by:
Hello all... I can't remind which function to use for safe inputs... gets, fgets, scanf leads to buffer overflow... i compiled that code with gcc version 2.95.2, on windows 2000 char tmp0 =...
285
by: Sheth Raxit | last post by:
Machine 1 : bash-3.00$ uname -a SunOS <hostname5.10 Generic_118822-30 sun4u sparc SUNW,Sun-Fire-280R bash-3.00$ gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/...
7
by: CaptainnFungi | last post by:
Hi All, I am very new to C and have been working my way through a few C books with the aim of getting more knowledge in programming. However I have hit a wall and I am not sure how to get over it....
27
by: Jeff | last post by:
Im trying to figure out why I cant read back a binary file correctly. I have the following union: #define BITE_RECORD_LEN 12 typedef union { unsigned char byte; struct { unsigned char type;...
26
by: Bill Cunningham | last post by:
I was talking with someone about fgets and he said that fgets puts the \n in a string but not \0. I decided to test this assumption because my documentation didn't say if fgets put \0 after a...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

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.