This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug network/14687] valgrind warning of uninitialised byte(s) in res_send.c


http://sourceware.org/bugzilla/show_bug.cgi?id=14687

--- Comment #3 from Siddhesh Poyarekar <siddhesh at redhat dot com> 2012-10-25 02:01:37 UTC ---
(In reply to comment #2)
> 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.

In this particular case, something like this happening is unlikely because of
the specific way in which the code works. It is interface code between the
kernel and glibc, where the kernel initializes the uninitialized values. One
could argue that initializing these values would mask a kernel bug.

> 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?

I personally find any addition of code to this path unacceptable because it is
unnecessary. If you are looking for consensus in the glibc community, then you
can post your patch on the libc-alpha mailing list. Please follow the
guidelines given in this link to post:

http://sourceware.org/glibc/wiki/Contribution%20checklist

-- 
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]