> -Wall over that codebase produces huge amounts of noise rendering it practically useless

As a c++ developer I would nope the hell out of there or spend a month fixing the warnings - depending on pay. No way would I work with something in that state long term.

> until somebody gets to fix all warnings which are not bugs.

Code that is filled with ignored warnings generally gets worse, not better. Having little to no quality standards does that.

Especially a security critical program, you really need to be using bug discovery tools as much as possible.

You might even find some zero days just by addressing all the warnings.

I think that's kind of OP's point... Use a more modern language that actually treats these kind of bugs (and many many others) as errors rather than as optional warnings.

There's a reason practically no one uses a memory-safe C++ implementation.

Not only that, but using different compilers will also cover more possible warnings.

You can have code without any warnings in clang, gcc and msvc++ compilers and it is probably better than code tested with only one compiler.

Doing C/C++ without -Wall, and/or not continuously fixing the things it shows[0], is pretty insane to me. The compiler is there to help you.

--

[0] - even if by ignoring them, when you're absolutely sure what you're doing.

Yep. I'd add that if it's a warning you're absolutely certain of, use the warning control pragmas to suppress them, and document why the warning's suppressed. Keep the compiler output clean so you can see where you need to examine.

Yup. I'm a big fan of

  -Wall -Wextra -Werror

If these options are set before you write any code, then these problems don't arise.

Worth noting you should probably disable -Werror for distribution if you expect users to compile your code. They aren't going to fix your error for you and you can't know what warnings will be added to future compilers, nor what previous compiler versions marked as errors. Among many other people saying the same thing see [0] if you don't trust me.

Also IMO you often want to explicitly disable a few of those from -Wall and -Wextra -- Looking at the last c++ project I wrote, I turned off a few things like `-Wno-unused-parameter` for example.

[0]: http://blog.schmorp.de/2016-02-27-tidbits-for-the-love-of-go...

Absolutely agree.

As you get further into a project you tend to need subtler tools. But for the rough work when starting out, my preference is to be stricter, which can be relaxed as necessary, rather than starting out lax and reaching a point where tightening becomes Sisyphean.

Or if you're using clang you can just

  -Weverything

Which does actually turn on all warnings (so you'll probably want to add things like -Wno-unused -Wno-padded).

Under gcc, '-Wall -Wextra -Wpedantic' does not enable all warnings. There are still more than 40 flags you have to give if you really want all of them.

The reason why boggles my mind to this day.

Zcash, for example, is built with `-Werror` (edit: not `-Wall`, but we're working on that). So this is absolutely feasible on a Bitcoin-derived codebase.

Exactly. That's what I meant by "ignore"; "suppress" was the word I was looking for.

In any trusted codebase fixing every -Wall warning is the least you should aim for, possibly with a few intentful exceptions. Not doing so is very sloppy.

Running static analyzers (PVS-Studio, for example) and splitting up functions to simple things should at least make it easier to detect errors.

For splitting, there's a balance you need to strike. Split things up too far and the errors are definitely harder to detect.

IMO rote splitting usually doesn't simplify, it just hides the complexity.

Thats what I did when I joined an OSS C++ project. It's a great task for someone that wants to learn disparate parts of the code base.