Hacker News Reader

Comment by kazinator | Hacker News Reader

If you set warnings to errors, and upgrade your compiler from time to time, you're asking the compiler people to help find hitherto undiscovered issues in your code using the latest diagnostic tools that they have come up with.

If you don't want to be informed, then don't do that. But those issues could be real bugs.

For instance, one fine day GCC got the ability to diagnose situations when the indentation of an nested if statement is deceptive compared to the actual precedence of the clauses. So if someone had warnings as errors, and had such a statement, then their build stopped. If that was a real bug, they were grateful.

View on HN

Please, please, please don’t do this for end-user compiled software, because someday they’re going to be using a more modern compiler than you and their build is going to break because of new warnings that you couldn’t anticipate.

There is a sane alterantive: keep your code free of warnings, so that they stick out like a sore thumb, so that you then take them seriously in order to ... keep your code free of warnings. Disable anything you don't intend to fix; don't leave it littering your build output.

A clean build looks like this

   CC foo.o
   CC bar.o
   CC parser.o
   parser.c:42: warning: new thing found here (-Wnew-thing).
   CC lexer.o
   ...

you hide all the details of the compiler command line so the diagnostics stand out.

Warnings-as-errors is just a kind of negotiating hammer that is useful in team situations, when the developers have gotten used to ignoring new warnings, usually because they are hidden among reams of ignored old warnings.

Also, in a compiler that has a GCC-like interface, you can turn specific warnings into errors, which is useful. If there is something you don't tolerate in the code base, and it happens to be diagnosable as a warning, then you can error it.

GCC turns some required ISO diagnostics into mere warnings, like say assignments between incompatible pointer types. That kind of thing may be worth turning into an error.

I've had to remove deprecation warnings because downstream users enabled warnings as errors in their releases. They could fix newer versions of their software, but being able to build old versions on new dependencies was a requirement.

The solution was to introduce a deprecation message that wasn't technically a warning, and warn about the upcoming depreciation warning.

The solution with a compiler that has a GCC-like interface is to use -Werror=<specific-thing>. Not -Werror globally for all warnings that currently exist and that will exist henceforth.

Is there any reason why the user in question couldn't turn off warnings at that point if they don't want to bother with it?

The best approach I've seen is to make it easy to toggle Werror, but make sure each PR and all automated builds are built with it on. Werror off by default makes more sense if you have more non-developers building it than team members.

When do end users compile software but don't want to fix bugs?

When the bug they're being forced to fix does not affect them. This can happen when they want to make some other change, or maybe they don't even need changes, they just need a build that doesn't exist.

New warnings usually do not indicate real bugs. Sometimes they do, but usually they are false positives. -Werror causing a build to fail is strictly worse than the alternative (working roughly as well as before, sometimes slightly better or worse due to new optimizations). This is the direct cause of "software decay" here. The software would not "decay" nearly as much without -Werror.

Often a technical linux user will want to download a source tarball for a particular version of a utility or program, and build it on or for a particular linux distro they're using. They usually do not want ad-hoc modifications done to the source of all the specific utility versions they compile for their system this way.

When that's the only way to just get the software, because there is no binary package. If it doesn't build or run, some users just give up and go onto something else.

Sometimes the package maintainers who make binaries for themselves and others don't want to fix bugs. At most some minor build things, but something actually broken is punted upstream.

You may see behaviors like the program being disabled (unavailable) for some platforms because it couldn't build or tests didn't pass. Or the package will stay on the old version of the program: 1.2.3 isn't building, so we just give up for now and stick with packaging 1.2.1. Maybe 1.2.4 will fix it. In these situations, package maintainers will not always contact upstream; the developer doesn't know unless they go into that distro's site and search the issues for activity related to their program.

Reply on news.ycombinator.com