> The time you're spending reviewing warnings, determining warnings don't make sense, and individually suppressing warnings sounds like it could be considerable.
It can be. The thing is, I still spend more time debugging than writing code. The question is: Does this category of warning save me more time in bugs prevented that I don't need to debug, than it takes to review and suppress false positives? If not, I can disable the entire warning category. But otherwise - the considerable cost saves an even more considerable cost in debugging!
Now, the time reviewing warning categories also takes some time, but it's been absolutely worth it in my experience. Even warnings which don't make sense to leave enabled globally can be useful - there are times when they make sense to force-enable locally.
Clang can generate warnings about these two structures:
struct foo { char c; /* 3 bytes implicit padding */ int i; };
struct bar { int i, j, k; /* possibly 4 bytes of implicit padding */ };
Totally worthless for 99% of my code. But if these structures need to be exactly the same memory layout between multiple compilers with different implicit padding rules - because they're memory mapped, or serialized as a simple char[] blob, or whatever else, it's a very useful warning to enable around the struct definitions! (I'll combine this with static asserts about structure sizes to seal the deal. No, just because they're the same size doesn't mean they were padded the same between compilers!)
I've spent weeks tracking down issues that eventually turned out to be serialization mismatch related. Yes, it can be that subtle. I assume I saved at least a week between the multiple times I or a coworker triggered the warning-as-error modifying the structure. It took maybe a minute to look up the right warning, and to wrap the code in the relevant pragmas to force-enable it just for those structures. Worth!
> I wonder if the argument for/against -Werror is really the difference between the beliefs "a compiler warning is probably a problem in my code" vs "a compiler warning is probably a problem in the compiler"
For me it's "I want to review every warning type, and decide how to handle it".
Some of them are probably a problem in my code. These should remain errors - I need to fix them.
Some of them are probably a false positive, but catch big issues that make it worthwhile anyways. These should remain errors - I can suppress them.
Some of them are probably a false positive, and don't catch big issues, and just waste my time. These shouldn't even be warnings - I can disable them.