Bug 18316
Summary: | stdio problems with fscanf | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Chris Stuber <imap> |
Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 7.0 | CC: | dr |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2000-10-05 05:25:12 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Chris Stuber
2000-10-04 09:52:16 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. Ok, fix posted to http://sources.redhat.com/ml/libc-hacker/2000-10/msg00008.html will wait for feedback from other glibc hackers and if it is accepted, it will make it into the upcoming glibc errata. Jakub, 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 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. |