Red Hat Bugzilla – Bug 18316
stdio problems with fscanf
Last modified: 2008-05-01 11:37:59 EDT
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:
Compile/Run... and you get:
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.
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.
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.
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.
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
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.