Hacker News Reader

Comment by slacka | Hacker News Reader

Many answers suggest passing -Wall -Wextra to the compiler. In my experience, this misses many useful warnings. Here's a good list of additions warnings that usually produce useful results:

https://kristerw.blogspot.com/2017/09/useful-gcc-warning-opt...

View on HN

I never really understood why "all" wasn't actually a catch-all. If it's not a catch-all, don't call it all. Or at least give us a -Wallyesreally, which doesn't currently exist afaik

GHC (Haskell) has -Weverything which is great for this. I’d much rather get all warnings and blacklist the few I don’t want

-Weverything is also part of clang. An example of a warning is "this struct has a padding byte between these two fields." A blacklist would be painful.

-Weverything should be thought of as a tool for discovering new warning flags relevant to your project. Add those flags, but don't enable -Weverything for routine builds, unless you're a masochist.

Barrow/compiler-warnings is a nice reference for all Chang and gcc warning flags, which flags implicitly enable other warnings, and in which compiler version they were added:

https://github.com/Barro/compiler-warnings/

Clang has -Weverything:

https://clang.llvm.org/docs/UsersManual.html#diagnostics-ena...

The problem with -Wall is that people use it with -Werror, thus compilers would have to be very conservative about adding new warnings to it. Hence the situation we are in with a few flags "above and beyond". Most of -Wpedantic for example is not something I'd want to break my build on.

The following stack overflow answer has some good example of other warnings you probably don't want, but would be included in -Weverything: https://stackoverflow.com/questions/11714827/how-to-turn-on-...

I'd argue that if you used -Wall and you got all the warnings you can't really complain too much because you got exactly what you asked for.

That's fine for an argument in a bar, and not so helpful for people who are doing software engineering with code that is developed under multiple compiler versions. Or who build old code versions with a new compiler version.

Why are "people who are doing software engineering" expecting to build code in a new compiler without migration effort, and ignoring new warnings that have been added potentially pointing to existing undetected issues just so the code continues to compile?

"People who want to get shit done", sure. Pragmatists, even.

It's only not so helpful because -Wall is badly named and now we're forced to deal with that legacy. Ideally, -Wall would be the same as clang's -Weverything, and there'd be a -Wstandard (or something) flag for what -Wall currently does.

How often do you get warnings that aren't either real bugs or trivial to fix anyway?

The problem with ignoring warnings is that they tend to accumulate and before long you can't see the ones you really do need to pay attention to. And yes that means you have to take the time to cleanup on new compilers with more warnings.

The issue really isn't with -Wall, it's with -Werror. If I release an open source package that compiles fine today with -Wall -Werror, and tomorrow there's a new compiler release that adds a new warning to -Wall, then that adds a new error to my package, and users trying to compile it with a new compiler will fail and complain. They didn't ask for -Wall -Werror, they only asked for some program that produces a working executable with ./configure ; make.

Like enabling assertions or not, this is (a matter of opinion, and) a difference between "development" and "release" compilations. Ideally we would consistently use something like ./configure --devel for one and ./configure --release for the other. Other languages' build systems have this built in, and building a tarball with autotools used to do something similar, but if you just pull something off GitHub it's not clear what mode you'll end up with.

> Ideally we would consistently use something like ./configure --devel for one and ./configure --release for the other. Other languages' build systems have this built in

Makefile has this built in too; you'd just be saying "make development" instead of "make --development".

If you need to write specific rules for it, I wouldn't call it "built in". But sure, it's possible. But there is no general consensus across projects to do it, and do it the same way.

LOL. I did not realize "all" was not all. Jesus Christ. Maybe I will finally be able to figure out what is causing my program to crash.

I’d recommend using a sanitizer rather than relying on compiler warnings for this.

I tried to use some sanitizers but they seemed unavailable for my system. I am on MSYS2 with GCC 9.

What about gdb?

Is it possible to use gdb as a sanitizer or something? gdb usually works great for me but the backtraces and random crashes make me think it's actually some kind of memory corruption.

If Valgrind supports your platform, or if you can also build for a supported platform, then that will likely help you find your crash.

Yeah it doesn't. I mean there is an old version that supposedly works with mingw but it seems outdated and I couldn't get it to build.

Windows has something resembling ASAN, you could try running your application with some/all checks enabled.

https://docs.microsoft.com/en-us/windows-hardware/drivers/de...

Yeah I tried that. Can't remember for sure if I was able to get it to work for my program or not but I think not.

wow, I'm astonished that -Wshadow is not enabled by either -Wall nor -Wextra

Lots of shadowing is present in existing codebases, sometimes by design.

Reply on news.ycombinator.com