Bug 18316 - stdio problems with fscanf
Summary: stdio problems with fscanf
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-10-04 09:52 UTC by Chris Stuber
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-10-05 05:25:12 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Chris Stuber 2000-10-04 09:52:16 UTC
fprintf() and fgets()  never get EOF from streams.
It seems to read the last line over and over and never gets EOF (-1).

Incompatible ABI, shame on RedHat for making such a poor decision.
RH7 is broken big time and you leave us twisting in the wind with no
warning about the major pitfalls of the unstable compiler and glibc

test.txt contains 2 lines:

First Line
Last Line

#include <stdio.h>

FILE *in;
char buf[256];

while(fscanf(in,"%[^\n\015]\n",buf)!=EOF) {

Compile/Run... and you get:

buf=Last Line
buf=Last Line
buf=Last Line
buf=Last Line
buf=Last Line
buf=Last Line
buf=Last Line
buf=Last Line
buf=Last Line
buf=Last Line
buf=Last Line
buf=Last Line
buf=Last Line
buf=Last Line
buf=Last Line
buf=Last Line
buf=Last Line
buf=Last Line
buf=Last Line
buf=Last Line
buf=Last Line
buf=Last Line
buf=Last Line

Comment 1 Jakub Jelinek 2000-10-04 11:34:29 UTC
I don't know how is this related to fgets, fgets never returns EOF and I don't
see anything broken with it.
I'll work on fixing the _IO_vfscanf bug right now, thanks for the testcase.
On the other side, I think the rant was unnecessary, *scanf family has many
known serious bugs in glibc 2.1.x which are fixed in glibc 2.1.9x, plus if you
have not reported this, this bug would most probably make it into stable
glibc 2.2, which will appear very soon.
*scanf in this case btw does not return the last line over and over, it just
returns 0 for 0 matched arguments (and thus buf is left untact). It should
return EOF in this case though, yes.

Comment 2 Jakub Jelinek 2000-10-04 13:00:34 UTC
Ok, fix posted to
will wait for feedback from other glibc hackers and if it is accepted, it will
make it into the upcoming glibc errata.

Comment 3 Robert Thomas 2000-10-05 01:38:55 UTC
I cannot get your posted patches to apply to the SRPMS that came with 7.0's ISO
image.  The vscanf.c file gets totally rejected and the line numbers look way
off.  The second file gets patched correctly.  I'm just not sure this fixes the
problems though.  Ironically when I tried the code on my 7.0 machine fscanf and
fgets worked fine due to the libsafe library (I'm NOT running the RH7.0 libsafe,
I have the AT&T libsafe-1.3 compiled from source under 6.2 distribution).

Are your patches in respect to glibc-2.1.92-14.src.rpm?  Otherwise I don't think
imap can apply these patches and get his stuff running again.

Comment 4 Chris Stuber 2000-10-05 05:07:13 UTC
Yes, unable to patch glibc-2.1.92-14.src.rpm     Maybe the diff was for later version?

Noted on the libsafe stuff from the http://www.bell-labs.com/org/11356/libsafe.html
That worked well and saved my butt today.  It would be really sweet if the glibc-hackers 
could build that libsafe stuff into glibc2.2 to appropriately deal with some of these 
unsafe functions like fscanf().  I very much like the notion of logging buffer/stack 
overflow as they are the source of many hacks    Is this a reasonable suggestion?

Jakub is correct about fgets() working as advertised.    Sorry about the rant, but mucho
thanks and praise for the support.  

Comment 5 Jakub Jelinek 2000-10-05 05:25:10 UTC
The patch was actually against CVS as of yesterday (and is already
in CVS), so no, it does not apply to 2.1.92.
I'll be spinning new glibc rpms today after I debug some dlclose
issue in xmms plugins, then it has to go through QA and will be
released afterwards.

Concerning libsafe, I'm well aware it, there is a problem with it
on i386 though: if you compile some of object files with
-fomit-frame-pointer, then libsafe will do weird things, reporting
buffer overflows where they don't happen, crash the programs etc.
On other architectures, like sparc (or I think ia64) where
-fomit-frame-pointer does nothing, it might be a good idea to put
libsafe support into glibc (well, glibc build would build one more
shared library libsafe.so.x), I just had no time to work on that
yet, would need to discuss it with other glibc hackers and it
definitely cannot make it into glibc 2.2.
It would not be written as a wrapper library though, instead it
would add some assembly stuff to strcpy and the like and small
assembly startup before *printf and the like.

Note You need to log in before you can comment on or make changes to this bug.