On Thu, Jan 27, 2022 at 11:37:29AM +0100, Mark Wielaard wrote: > Hi, > > On Thu, Jan 27, 2022 at 10:41:36AM +0100, Roberto Ragusa wrote: > > On 1/22/22 10:05 PM, Mark Wielaard wrote: > > > > > So I would give valgrind a 6/6 (100%) score :) > > > > But if the compiler starts copying zeros on uninitialized memory, > > valgrind loses any ability to detect the defect in the code. > > Yes. So that is the compromise. You'll always get initialized zeros > for local variables, so any usage is defined (though probably buggy). > But some of the tools, like valgrind memcheck, will be unable to > detect the buggy code. > > If you believe the tools we have are pretty bad to begin with and/or > not actually used by people to find such bugs then this is a good > compromise. If you believe the tools are pretty good for detecting > these issues (and I believe they are, the example given was just > unfortunate because some of the issues weren't actually bad code and > some others were rightfully optimized out, so would never trigger), > then it is a bad compromise. But we definitely need to encourage > people to use the tools more. It isn't about whether the tools are good or bad. We have many great tools, valgrind included. It about the practicality of using the tools to achieve the same end goal - no use of uninitalized memory. Valgrind is only win, if it is practical to actually exercise every codepath in question to detect the latent problems. Unit testing coverage for most projects is nowhere near good enough to exercise all codepaths. Nor is any other functional/integration testing that is done, if any. Error code paths are a particular problem since they're rarely exercised by normal users, and difficult to exercirse in tests without clever fault injection techniques. If you have unlimited developer resources, you might write tests to exercise every relevant code path and put this all through valgrind and become confident you don't have uninitialized variables. Even then, valgrind isn't practical for some apps because of the performance penalty it imposes. So awesome as valgrind is, from a real world practicality POV, it is a clear win to let the compiler default initialize every variable to zero. It will eliminate a whole class of bugs that will never be reliably identified by the developers, allowing them to spend more time dealing with more important classes of bugs or work on features or whatever else deserves their very limited time. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
