This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug network/14687] valgrind warning of uninitialised byte(s) in res_send.c
- From: "timothy.c.pepper at linux dot intel.com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Wed, 24 Oct 2012 21:18:30 +0000
- Subject: [Bug network/14687] valgrind warning of uninitialised byte(s) in res_send.c
- Auto-submitted: auto-generated
- References: <bug-14687-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=14687
--- Comment #2 from Tim Pepper <timothy.c.pepper at linux dot intel.com> 2012-10-24 21:18:30 UTC ---
(In reply to comment #1)
> It's a spurious warning by valgrind since relevant fields are initialized
> correctly. It does not make sense to add cruft just to make valgrind happy.
I can see that assessment.
But it is also a spurious warning that given the code path many many many
developers will have to see, worry about, spend time analyzing, and finally be
able to mark off their list of potential sources for whatever oddity they were
debugging once they've figured out what glibc is doing, and then they add a
valgrind suppression to their codebase. That leads to a lot of extra work
glibc causes other developers and leads to cruft in their codebases. Worst
case the glibc code evolves somehow to actually use the uninitialized fields
and rather than valgrind-using developers helping catch this, they've
suppressed it already at their end. This is not positive for overall distro
supportability and maintenance.
If the memset is cruft, the fields unused in this code path are cruft. Would
you find more acceptable the patch to differentiate the data structures used in
the send and receive paths, along with all the associated code changes to the
places that would need to use the new data structures?
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.