On Mon, 2019-12-16 at 15:45 +0100, Martin Jambor wrote: > 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? Fair point. And I've certainly seen painful-to-fix fallout in my Fedora builds -- by far the most painful cases have been addressables where we're able to strip the address-of due to inlining. > > > 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. If it's coming from our headers, then we make a huge effort to fix the issues :-) jeff
