Live data from Hacker News

Don't use -Werror

blog.schmorp.de

11–20 of 74 posts

Re: Don't use -Werror

#11

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?"

Have you ever used multiple compilers? Try compiling the same thing written in C or C++ with: clang, then gcc, then icc and see how -Werror treats you within any remotely interesting code. It's hard to predict what one compiler feels is perfectly okay (or perhaps ambiguous) and another feels is downright wrong. It's downright infuriating in a cross-architecture environment. -Wall -Wpedantic and -Wextra are usually plenty.

Re: Don't use -Werror

#12
So, clever bloke declares error checking is wrong or something.

As a non serious programmer it would seem to me that -Werror is either not granular enough or simply not fit for purpose.

I wonder if -Werror is defined in a standard somewhere and hence has a clearly defined meaning.

Re: Don't use -Werror

#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 bugs, or should be squelched per false positive, or should be squelched project-wide.

> Two recent examples are squid and qemu-linaro, two packages I had to compile from source as Debian GNU/Linux didn't have (good enough, or any) packages for them.

The fundamental problem here is using a contributor's build environment (where I want -Werror to get them to contribute warning-induced bugfixes, or squelches/ignores if they're really false positives) for a non-contributor's task (where they just want the final binary, and aren't going to bother reporting the warnings even if I want them.)

Non-contributors building from source isn't a relevant niche to me (I generally ship binaries), but I can sympathize with the request for a warnings-as-warnings fast build path for them.

But make -Werror the default build path, for developers. This needs to be opt-out, not opt-in.

Re: Don't use -Werror

#14

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?"

There are only 2 go compilers, with very few warnings. C has a whole bunch of compilers and some of them have a whole bunch of warnings.

Re: Don't use -Werror

#15

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 language and I think it pretty accurately reflected a lot of my own experience with it.

edit: found it [0]

[0] http://ridiculousfish.com/blog/posts/go_bloviations.html

Re: Don't use -Werror

#16

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 only errors on a small number of things and, while some of those things would be warnings in other languages, I don't think it's fair to frame them in that light.

The go compiler strives to not print any output at all pretty much, and it does that by not having any warnings at all.

If you want warnings in go, you use tools like "go vet" which tell you "this bit is indicative of an issue".. the go compiler won't give that to you though.

As other replies said, Go also doesn't have many compilers. Really it's only 1 supported one. They also don't add new "errors" to the compiler over time for this compatibility reason pretty much.

Re: Don't use -Werror

#17

I use -W4 and -WX with MSVC to enable the highest warning level and flag all warnings as errors. Then I disable a couple of the more pointless warnings (unreferenced formal parameter, unreferenced local function, unreachable code...) that would otherwise keep me from being able to use -W4 without jumping through arbitrary hoops. The problem with GCC, at least at the time I was using it several years ago, is that ther…

GCC has pretty much always had `-Wno-YOUR_SPECIFIC_ERROR`.

By that, I mean it was present in a random version from 1993 (2.4.5). But it wasn't there in 1987 (1.35, the oldest version that can be easily downloaded), so it didn't literally always have it.

Edit: I wasn't satisfied not knowing; so I dug through some more versions. The -Wno- flags were introduced in GCC 2.0 (1992). (Though only tracked down 1.41, not 1.42, the last of the 1.X line).

Re: Don't use -Werror

#18
post #11

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?"

Have you ever used multiple compilers? Try compiling the same thing written in C or C++ with: clang, then gcc, then icc and see how -Werror treats you within any remotely interesting code. It's hard to predict what one compiler feels is perfectly okay (or perhaps ambiguous) and another feels is downright wrong. It's downright infuriating in a cross-architecture environment. -Wall -Wpedantic and -Wextra are usually pl…

> It's downright infuriating in a cross-architecture environment

The only thing more infuriating than being unable to predict when your code is going to fail the build because of -Werror on some other compiler/arch, is your bugs generating warnings on some compiler/arch es that don't fail the build. Cross-architecture environments are one of the main reasons I want to enable -Werror and kin. I won't notice all the warnings otherwise.

Re: Don't use -Werror

#19
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.

I agree whole heartedly. When I'm programming I typically want most things that would cause a warning to stop me in my tracks. However I cannot count the number of times I've been trying to build someone else's code and the configuration uses -Werror and things that didn't raise a warning on their version of gcc or clang do on mine and now I've got to fix possibly dozens of not actual errors.

Re: Don't use -Werror

#20
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.

Yes exactly. For example GNU coreutils auto enables -Werror for devs when running from a git repo, whereas tarball releases do not add that option. See:

http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=blob;f=confi...

Post reply on HN