|
From: John R. <jr...@bi...> - 2010-04-09 14:53:15
|
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. -- |