Hacker News Reader

Comment by soulbadguy | Hacker News Reader

genuilely curious : Do you have a class of warnings or a warning in particular you think should be left out of Werror by default ?

View on HN

The deprecated attribute is useless when -Werror and -Wall are both on. You can't land the attribute if any uses exist because any use is now a compiler error. You might as well just delete the entity and sort things out from there.

Normally you can pragma turn the error off for each use. I'm meaning to dp this for stuff where our ABI must support the function but I don't want anyone to use it otherwise.

The issue is that not every snapshot of a source file is intended to be committed as-is.

So it really depends if you're testing code or committing it. When you're debugging something locally, warnings like "unused parameter" or "dead code" become extremely annoying as errors. I need to be able to put "return 0;" in the middle of my function and run it as-is without having to battle the toolchain for five minutes after that every damn time.

Of course i don't have the specifics of your usual configuration. But usually this mostly a configuration problem. Dev builds usually don't have -Werror turned on ( or have a very easy way to turn Werror off). In most project i worked on, Werror is informance on the release, and continious test builds.

But i do agree that Werror on the code/build/test cycle sound like a pain.

I mean sure, you can work around any problem if you put enough effort into it. For this particular problem, in reality it introduces friction. e.g., one practical problem you face (if you've put sufficient work into your tooling to get to this point) is that your "dev" builds will now miss the cache far more often, because CI is running with different flags. Again, you can work around that... by (for example) spending more money and energy building with different flags. Nothing is impossible to do with enough investment, but these don't come free.

A couple are kind of annoying, such as sign conversion/comparison.

Most security/safety feature either on the language or the tooling side are are some what annoying since by definition they tend to add constrains to one workflow. The real question is whether they introduce more pain than they safe in average.

Right, I understand that. I'm overwhelmingly in support for most warnings. I just think that a handful don't have good tradeoffs or are not necessarily the most valuable for many projects.

Reply on news.ycombinator.com