Hi Jeff, On Sat, Dec 07 2019, Jeff Law wrote: > [...] > The whole point behind the uninitialized warning is to capture cases > where objects may not be properly initialized. For modern code the > simple cases typically "just work". What is by far the most > interesting cases are those with complex flow control, often > interacting with inline functions, address-of stripping, etc. These > are precisely the cases that humans aren't particularly good at > catching and having the compiler analyze those paths and issue warnings > that humans fix ultimately results in better quality code.
Or "fixes" like: https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/expmed.c?r1=277864&r2=277863&pathrev=277864 if even we cannot deal with the false positive in our own compiler, how can we expect our users to do so? > > Experience has shown that if you put something in -Wall, people will > pay attention to it, and that is good for the long term quality of code > bases. If the diagnostic is outside of -Wall, it's largely ignored. I > think the pain of dealing with the Wuninitialized warts is smaller than > the pain of allowing these errors to persist. I'm afraid I that -Wmaybe-uninitialized is getting out of hand. I bet that some users regularly get these warnings coming from c++ header "libraries" (like they sometimes come out our vec.h which recently "broke" bootstrap) which they sometimes even cannot change and they then conclude that our -Wall is "unusable" and stop paying attention to all warnings. Martin
