Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't use -Werror

blog.schmorp.de

Post reply on HN
Print view View original

41–50 of 74 posts

Re: Don't use -Werror

#41

Post by brian-armstrong »

andrewchambers wrote: post #32
MaulingMonkey wrote: post #13

> Enabling -Werror in distributions virtually guarantees that they won't build: Even if you took care of all compiler warnings in all compilers for which you enable this switch, it's just a question of time till a new compiler version comes along that has a new warning message and - BOOM. This is a feature. This triggers a review of the new warnings introduced by the new compiler version, to see if they have found bu…

> This is a feature. This triggers a review of the new warnings introduced by the new compiler version, to see if they have found bugs, or should be squelched per false positive, or should be squelched project-wide. The thing is, the software already had these bugs, and worked well enough for most people despite them, its not worth breaking the build over unless you are the developer.

Those bugs could be buffer overruns or similar security problems. Just because the program appears to work doesn't mean it should be used.

Re: Don't use -Werror

#42

Post by csl »

MaulingMonkey wrote: post #13

> Enabling -Werror in distributions virtually guarantees that they won't build: Even if you took care of all compiler warnings in all compilers for which you enable this switch, it's just a question of time till a new compiler version comes along that has a new warning message and - BOOM. This is a feature. This triggers a review of the new warnings introduced by the new compiler version, to see if they have found bu…

It might be okay for your project, but there are many cases where warnings seriously get in the way (e.g., indirect throw/longjump but leaving out a return statement).

Besides, the warnings depend on the compiler (which may be non-gcc/clang/vs) — and may not even make sense on a given system. So shipping with -Werror is not really a good idea. Put the important stuff in the tests.

Re: Don't use -Werror

#43

Post by andrewchambers »

brian-armstrong wrote: post #41
andrewchambers wrote: post #32

Earlier quoted context omitted.

> This is a feature. This triggers a review of the new warnings introduced by the new compiler version, to see if they have found bugs, or should be squelched per false positive, or should be squelched project-wide. The thing is, the software already had these bugs, and worked well enough for most people despite them, its not worth breaking the build over unless you are the developer.

Those bugs could be buffer overruns or similar security problems. Just because the program appears to work doesn't mean it should be used.

They could be, or they could be nothing, and the program might not even be exposed to untrusted input anyway.

We can have a discussion about perhaps splitting programs into security classes, though I would prefer the upstream people use the cutting edge security analysis, then backport patches with security advisories.

Re: Don't use -Werror

#45

Post by quotemstr »

forgotpwtomain wrote: post #15
ridiculous_fish wrote: post #3

Go has the equivalent of -Werror on all the time. How does it address the issue of "your compiler might emit a warning that my compiler didn't?"

Go has something of an imposed rigidity that a lot of C programmers I think wouldn't tolerate well (culturally, viscerally),- one example: the whole comment out all unused variables because you commented out a function for debugging purposes during development (couldn't just pass a flag to the compiler, at least last time I used Go). Aside - I seem to remember a Blog post you wrote on your experience with the Go lang…

Next time I write a Go program, I'm hacking the compiler locally so it stops whining about this "problem".

Re: Don't use -Werror

#46

Post by Nullabillity »

csl wrote: post #42
MaulingMonkey wrote: post #13

> Enabling -Werror in distributions virtually guarantees that they won't build: Even if you took care of all compiler warnings in all compilers for which you enable this switch, it's just a question of time till a new compiler version comes along that has a new warning message and - BOOM. This is a feature. This triggers a review of the new warnings introduced by the new compiler version, to see if they have found bu…

It might be okay for your project, but there are many cases where warnings seriously get in the way (e.g., indirect throw/longjump but leaving out a return statement). Besides, the warnings depend on the compiler (which may be non-gcc/clang/vs) — and may not even make sense on a given system. So shipping with -Werror is not really a good idea. Put the important stuff in the tests.

> indirect throw/longjump but leaving out a return statement

Hopefully a modern language would have a divergence type.

Re: Don't use -Werror

#47

Post by MaulingMonkey »

csl wrote: post #42
MaulingMonkey wrote: post #13

> Enabling -Werror in distributions virtually guarantees that they won't build: Even if you took care of all compiler warnings in all compilers for which you enable this switch, it's just a question of time till a new compiler version comes along that has a new warning message and - BOOM. This is a feature. This triggers a review of the new warnings introduced by the new compiler version, to see if they have found bu…

It might be okay for your project, but there are many cases where warnings seriously get in the way (e.g., indirect throw/longjump but leaving out a return statement). Besides, the warnings depend on the compiler (which may be non-gcc/clang/vs) — and may not even make sense on a given system. So shipping with -Werror is not really a good idea. Put the important stuff in the tests.

> It might be okay for your project, but there are many cases where warnings seriously get in the way (e.g., indirect throw/longjump but leaving out a return statement).

I'd prefer to explicitly annotate the indirectly throwing function as non-returning, when possible. Longjumps are rare enough for me I'd be willing to individually suppress them, or suppress them over a range of code where they happen to be common. I've seen return warnings catch enough bugs that I believe this will save more time than it spends in the long run. If I didn't, I'd explicitly lower that individual warning's severity. I will also lower the warning's severity on a given compiler, if (but only if) I can't properly annotate it away on a given compiler.

> Besides, the warnings depend on the compiler (which may be non-gcc/clang/vs)

Again, feature. More coverage. Good.

> and may not even make sense on a given system.

In which case, upon reviewing said warning and determining said warning indeed does not make sense, said warning can be individually suppressed as mentioned.

> Put the important stuff in the tests.

This is a statically typed language. Successfully compiling is the first test. Successfully passing static analysis is the second test.

Undefined behavior bugs can lead to some very subtle behavior that can be very difficult to unit test for, and tends to be quite sensitive to things like compiler flags, which call site they were inlined at, allocation patterns, etc. to even manifest in the first place. Given how nasty they can be to debug, they're also some of the bugs I'm most interested in catching - ideally before I commit, definitely before I ship. Taking full advantage of compiler diagnostics is way easier than e.g. writing enough unit tests to catch all UB caused from falling off the end of a non-void function without a return statement.

Re: Don't use -Werror

#48

Post by skybrian »

MaulingMonkey wrote: post #13

> Enabling -Werror in distributions virtually guarantees that they won't build: Even if you took care of all compiler warnings in all compilers for which you enable this switch, it's just a question of time till a new compiler version comes along that has a new warning message and - BOOM. This is a feature. This triggers a review of the new warnings introduced by the new compiler version, to see if they have found bu…

This all depends on how much your compiler changes and how often you upgrade the compiler. Do you fix all the new warnings before upgrading? If it's a large codebase, that can take a while. Meanwhile your continuous build can't use the new compiler. (Or in practice, that's when you stop using something like -Werror and start disabling the new warnings.)

For most open source projects, it's probably not that big a deal. But for something large like a monorepo, we're talking about hundreds of millions of lines of code that worked before.

People should be able to use the new compiler while someone goes back and looks at the new warnings. Assuming it's a priority. This task isn't automatically more important than other work.

Re: Don't use -Werror

#49

Post by ars »

Sir_Cmpwn wrote: post #30
ars wrote: post #2

Summary: Enable -Werror in debug builds, disable it in production builds (in publicly released builds). Reason: -Werror is helpful for you, useless for a 3rd party.

Better if the third parties hit you up with the bug report and you come back with a patch.

A warning doesn't stop them from filing a bug report.

It doesn't have to be an error though.

Re: Don't use -Werror

#50

Post by [deleted] »

Sir_Cmpwn wrote: post #30
ars wrote: post #2

Summary: Enable -Werror in debug builds, disable it in production builds (in publicly released builds). Reason: -Werror is helpful for you, useless for a 3rd party.

Better if the third parties hit you up with the bug report and you come back with a patch.

[deleted]
Post reply on HN