This is the mail archive of the
glibc-bugs-regex@sources.redhat.com
mailing list for the glibc project.
[Bug regex/860] New: bad guard in find_recover_state do-while loop
- From: "svdb+sources dot redhat dot com-bugs at stack dot nl" <sourceware-bugzilla at sources dot redhat dot com>
- To: glibc-bugs-regex at sources dot redhat dot com
- Date: 19 Apr 2005 01:02:43 -0000
- Subject: [Bug regex/860] New: bad guard in find_recover_state do-while loop
- Reply-to: sourceware-bugzilla at sources dot redhat dot com
While compiling the regex code with extra warnings on, from outside libc, quite
a lot of warnings were reported. While these warnings were very justified, most
of the underlying problems would not cause the actual code to behave in a non-
intended way. But one is very much a bug:
In find_recover_state, err is compared to REG_NOERROR, while it is *err which
should be compared instead. Because of this the do-while loop will always
terminate after one iteration.
I was working on getting rid of all the warnings in the regex code, which was
taking quite a bit of time, as I needed to make sure I'm fixing the actual
problems, and not (just) the symptoms. But then I noticed that the GNU coding
guidelines stopped just short of saying "Listening to warnings to find a few
bugs is not worth the effort.", which would explain the mess I'm encountering. I
am willing to continue my work and submit a big patch with fixes that will clean
up this code somewhat, but before I continue, I'd like to know whether such a
patch will actually stand a chance of getting accepted.
--
Summary: bad guard in find_recover_state do-while loop
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: regex
AssignedTo: gotom at debian dot or dot jp
ReportedBy: svdb+sources dot redhat dot com-bugs at stack dot nl
CC: glibc-bugs-regex at sources dot redhat dot com,glibc-
bugs at sources dot redhat dot com
http://sources.redhat.com/bugzilla/show_bug.cgi?id=860
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.