Re: [Valgrind-users] Memcheck and a method to find when uninitialized memory gets copied ...

[John R. <jr...@bi...>]

On 04/08/2010 10:23 PM, Nicholas Nethercote wrote:
> It's easy to do, but gives bazillions of warnings even for the most
> trivial programs.  Even if you religiously avoid undefined values in
> your code (eg. by padding out your structs) all the libraries you use
> will copy undefined values around like crazy.

"All the libraries ... copy undefined values around like crazy"
might be an exaggeration.  For instance, I fixed all the instances
in several generations of glibc.  It was a slog at times, but not
totally impossible.  http://BitWagon.com/glibc-audit/glibc-audit.html
The maintainers of glibc were not interested.  I view that opinion
as short-sighted because I see it impeding software quality.  For
instance, every run of memcheck is measurably more expensive due to
catching and suppressing the glibc-specific uninit-but-don't-cares.
I believe that avoiding a single bug per project saves many multiples
of the space and cycles that are required to execute uninit-free.
About once per year per programmer, the analysis even _saves_ space
and cycles by identifying inefficiencies in layout or execution.

Similarly to the initial work that is required when running a never-
checked-before application under memcheck, then running with "no copy
of uninit bits" requires significant initial work.  Such work often
includes libraries which the application developer probably prefers
to ignore.  However, the benefits of a solid foundation accrue to
all clients on all runs, for as long as the library is used.  Today
the cost might seem high; in a while it will become quite small.
In practical terms, a major library might have 20 to 30 root causes
for most of its uninit copying.  About a dozen or so probably will be
quick and easy to identify, and then the others will be a long tail.

--