5 ms·

This is an example of why you shouldn't use blanket warning options like -Wall in combination with -Werror. Otherwise your program might fail to compile just be

by nialv7 7y ago

This is an example of why you shouldn't use blanket warning options like -Wall in combination with -Werror. Otherwise your program might fail to compile just because the dev randomly thought of some new things to warn about.

archi42 7y ago
We use -Wall and -Wextra, and fixed basically all our warnings. Now everyone writes virtually warning-free code (that is, any warning is fixed before committing). And I don't feel limited in what I can do. We could roll -Werror for most packages (I think we have a few packages, e.g. 3rd party libs, which emit warnings), but only use error=format and error=format-extra-args. To be fair, we disable these warnings (-Wno-...): unknown-pragmas, long-long, register, unused-command-line-argument.
- seba_dos1 7y ago
  I just keep my codebase warning free and check it in CI. No need for -Werror on package level, users don't need to deal with random breakage from a false-positive warning.
  - archi42 7y ago
    If you don't control the build env (e.g. FOSS work), then of course relying on -Werror might yield unnecessary trouble.
    - marcosdumay 7y ago
      You never completely control your build env. You are always relying on 3rd parties for some extent. That may not look relevant in short periods of time, but there are large odds that somebody will be biten by your choice of using -Werror 5 or 10 years down the road.
      - archi42 7y ago
        I would not sign that claim as a general truth. It's true under some assumptions, but then, well, just disable -Werror in 5 to 10 years? It's not like THAT is a breaking change. OTOH 5 to 10 years is a good way to accumulate plenty of warnings (assuming a lack of development discipline), which at some point makes it easy to miss that one critical warning that should really be fixed. Maybe I should mention the worst case for an error in the code I write is "people die" (static analysis of safety critical stuff), so that's a good motivation to have no warnings ;-)
adrianN 7y ago
You should always thoroughly check whether your program still works after upgrading the compiler. Adding a -Wno-bad-exponentation to your makefiles shouldn't be that difficult.
- nialv7 7y ago
  If you are the only one using your program, then that's probably fine. I cannot count how many times I have to patch other people's makefile so their code won't fail to compile because of some -Werror introduced in a newer version of the compiler.
  - inlined 7y ago
    I wonder if a script could be made that: 1. Adds pragmas around each error to suppress 2. Creates commit 3. Sends to upstream branch for review & triage 4. Bonus if hosted on GitHub, files an issue
TorKlingberg 7y ago
-Wall, despite its name, isn't actually all warnings. Compiler devs only rarely put new warnings into -Wall.
- floatboth 7y ago
  They do it often enough that OS package maintainers deal with build failures caused by Werror quite a lot. And forget new versions of compilers, how many things are only tested with GCC and fail to build with Werror with clang because of different warnings in Wall?
  - inlined 7y ago
    Is there info on how many of those new compiler errors were true bugs vs spurious?
    - lalaithion 7y ago
      It doesn't matter to the end user! If you have a bug in your code that can be detected by a new compiler warning, that's cool, but it shouldn't prevent your users from building their own version of your project.
pm215 7y ago
I like the intermediate position: enable -Werror for development builds (which for QEMU means "builds from head-of-git"), leave things as just warnings for (source) releases, and give the user an escape hatch (eg a configure --disable-werror option) in case they need it. Enforcing warning-free compiles for the average developer is really useful for maintaining a minimum quality bar, so it's good to find a way to keep that without annoying people who might be compiling from source but are essentially 'end-users' of it.
- marcosdumay 7y ago
  You don't need -Werror for enforcing warning-free compilation.

by nialv7 7y ago

archi42 7y ago

We use -Wall and -Wextra, and fixed basically all our warnings. Now everyone writes virtually warning-free code (that is, any warning is fixed before committing). And I don't feel limited in what I can do. We could roll -Werror for most packages (I think we have a few packages, e.g. 3rd party libs, which emit warnings), but only use error=format and error=format-extra-args. To be fair, we disable these warnings (-Wno-...): unknown-pragmas, long-long, register, unused-command-line-argument.

seba_dos1 7y ago
I just keep my codebase warning free and check it in CI. No need for -Werror on package level, users don't need to deal with random breakage from a false-positive warning.
- archi42 7y ago
  If you don't control the build env (e.g. FOSS work), then of course relying on -Werror might yield unnecessary trouble.
  - marcosdumay 7y ago
    You never completely control your build env. You are always relying on 3rd parties for some extent. That may not look relevant in short periods of time, but there are large odds that somebody will be biten by your choice of using -Werror 5 or 10 years down the road.
    - archi42 7y ago
      I would not sign that claim as a general truth. It's true under some assumptions, but then, well, just disable -Werror in 5 to 10 years? It's not like THAT is a breaking change. OTOH 5 to 10 years is a good way to accumulate plenty of warnings (assuming a lack of development discipline), which at some point makes it easy to miss that one critical warning that should really be fixed. Maybe I should mention the worst case for an error in the code I write is "people die" (static analysis of safety critical stuff), so that's a good motivation to have no warnings ;-)

adrianN 7y ago

You should always thoroughly check whether your program still works after upgrading the compiler. Adding a -Wno-bad-exponentation to your makefiles shouldn't be that difficult.

nialv7 7y ago
If you are the only one using your program, then that's probably fine. I cannot count how many times I have to patch other people's makefile so their code won't fail to compile because of some -Werror introduced in a newer version of the compiler.
- inlined 7y ago
  I wonder if a script could be made that: 1. Adds pragmas around each error to suppress 2. Creates commit 3. Sends to upstream branch for review & triage 4. Bonus if hosted on GitHub, files an issue

TorKlingberg 7y ago

-Wall, despite its name, isn't actually all warnings. Compiler devs only rarely put new warnings into -Wall.

floatboth 7y ago
They do it often enough that OS package maintainers deal with build failures caused by Werror quite a lot. And forget new versions of compilers, how many things are only tested with GCC and fail to build with Werror with clang because of different warnings in Wall?
- inlined 7y ago
  Is there info on how many of those new compiler errors were true bugs vs spurious?
  - lalaithion 7y ago
    It doesn't matter to the end user! If you have a bug in your code that can be detected by a new compiler warning, that's cool, but it shouldn't prevent your users from building their own version of your project.

pm215 7y ago

I like the intermediate position: enable -Werror for development builds (which for QEMU means "builds from head-of-git"), leave things as just warnings for (source) releases, and give the user an escape hatch (eg a configure --disable-werror option) in case they need it. Enforcing warning-free compiles for the average developer is really useful for maintaining a minimum quality bar, so it's good to find a way to keep that without annoying people who might be compiling from source but are essentially 'end-users' of it.

marcosdumay 7y ago
You don't need -Werror for enforcing warning-free compilation.