4 ms·

> It means your code may fail to compile on future compilers using your provided build scripts. Which is an advantage. If the compiler issues a warning that tr

> It means your code may fail to compile on future compilers using your provided build scripts. Which is an advantage. If the compiler issues a warning that triggers your -Werror then your code may contain bugs. A new version of the compiler may introduce a novel optimization step that causes code that takes advantage of some undefined behavior to crash. The way to detect this is to read the compiler warnings. Essentially, you the developer have only have two choices. 1) Users complaining about random mysterious crashes. 2) Users complaining about not being able to compile your software. 2 is always preferable to 1.

flohofwoe 5y ago
Especially in gcc and clang, many of the higher level warnings are more like style guide recommendations or "did you really mean this" warnings (like switch-case fallthrough, unused variables, or unused static functions). Also the fix is simple: -Werror for development builds, but not release builds. This way users can still compile even if they upgraded to a new compiler versions but haven't yet or can't update dependencies.
loup-vaillant 5y ago
I wrote a cryptographic library in C. The quality requirements for that kind of thing is pretty much "don't publish a single error, or Thomas Ptacek is going to haunt you for the rest of your life[1]". Or, you know, actual consequences that might arise from users using your broken crypto. Inevitably, I did publish some errors, one of which was actually critical. Here's how many would have been caught by a compiler warning not already present in GCC-8's -Wall -Wextra: Zero. None. Nada. Zilch. Mind you, I did have reports of some other compiler (mostly MSVC, but Clang with -Weverything as well) complaining about various weird things, including stuff like using bitwise operations on signed integers, or negation on an unsigned integer. They never lead to the discovery of an actual bug. On the other hand, one very important thing I did was using sanitizers extensively. ASan, MSan, UBSan, Valgrind, even the TIS interpreter (and now TIS CI), so I could weed out as much undefined behaviour as I could. And boy did those tools find actual bugs. Those, coupled with a proper test suite, will find all the bugs. The bugs I failed to find in time can all be traced with either not using the strictest runtime sanitiser, or a hole in the test suite. That being said, I still try very hard to be warning-free for most compilers out there. And I mostly am. But this is not about bugs. This is about sparing my users the headache that comes with investigating some trivial warning they should not care about. Monocypher does not need -Werror. [1]: I'm joking, he actually didn't.
- UncleMeat 5y ago
  All advice has exceptions. But I don't think it would be controversial to say that in most engineering organizations, -Werror will catch and prevent real bugs at a nontrivial rate.
  - loup-vaillant 5y ago
    I strongly suspect the reason is because they tolerate incomplete test suite, and don't use sanitisers enough, despite their use of an insanely unsafe language (one thing I absolutely hate about C is the sheer amount of undefined behaviour). -Werror is just a stop gap desperate measure for when devs are pressured to write crap as quickly as possible. What's exceptional about Monocypher is not really that it's a cryptographic library (though that helps, modern cryptographic code tends to have pathologically simple control flow), it's that I took the time to polish it. That being said, I am not against static analysis. On the contrary, I am huge fan of strong static type systems, and for languages like C a static analyser can be a huge help. I also trust John Carmack when he says running a static analyser has found non-trivial bugs in real code. But then I want real static analysis, that can assess actual risks of making mistakes. Compilers need to be fast, so their warnings naturally tend to be crude. And if they start complaining about stuff like whitespace in a language where whitespace has no semantics, that may hurt more than it helps.
    - UncleMeat 5y ago
      "Just write good code" is not a workable plan for most organizations of any size. You often want workflows that are resistant to "we promoted somebody to TL when they shouldn't have been and they are not doing a very good job" situations. Yes, it is outrageous that anybody still writes programs in C or C++, which basically guarantee that you'll write oodles of subtle bugs. Yes, static analysis that finds problems that you can't train humans to find is more interesting. Yes, sanitizers and fuzzing should be mandatory for any serious project in C or C++. But "hey, you've got a vacuously true branch predicate" is valuable in a large number of cases even if humans can catch that with tests, since most organizations are not able to successfully hire only excellent engineers and give them sufficient time to never be rushed. Just a few weeks ago Google shipped a branch condition that included & rather than && that broke all Chromebook logins. I submit this as evidence that it it not possible to construct a large organization that is resistant to bad code without automation. Yes, a lot of other things needed to go wrong to enable this code to reach production but so many of those processes are either done by humans (and therefore error prone) or produce the same complaints when mandated by automation (e.g., 100% line coverage).
nullc 5y ago
A warning being thrown for a user which is caused by a bug that leads to mysterious crashes in a codebase which is warning free for the developer is something which is almost unobservably rare. So sure, a user getting a failed compile is superior to a mysterious crash, but that isn't the actual tradeoff in practice. Instead, if you have a post compile test suite which covers extensively all branches in the code you will catch things like miscompilation that warnings have little chance of catching. And well constructed the tests can have a zero rate of false positives-- which isn't something you'll get from warnings. So another choice: take the time you'd spend on the sisyphean task of dealing with random failures due to Werror new/old/different toolchains and invest it on making better post compile tests and save the Werror for your CI where its time wastage is more proportional to the benefit it provides.
slavik81 5y ago
> Which is an advantage. If the compiler issues a warning that triggers your -Werror then your code may contain bugs. Even if the compiler doesn't issue a warning that triggers -Werror, your code may contain bugs. This is the root of the false dichotomy you present.

flohofwoe 5y ago

Especially in gcc and clang, many of the higher level warnings are more like style guide recommendations or "did you really mean this" warnings (like switch-case fallthrough, unused variables, or unused static functions). Also the fix is simple: -Werror for development builds, but not release builds. This way users can still compile even if they upgraded to a new compiler versions but haven't yet or can't update dependencies.

loup-vaillant 5y ago

I wrote a cryptographic library in C. The quality requirements for that kind of thing is pretty much "don't publish a single error, or Thomas Ptacek is going to haunt you for the rest of your life[1]". Or, you know, actual consequences that might arise from users using your broken crypto. Inevitably, I did publish some errors, one of which was actually critical. Here's how many would have been caught by a compiler warning not already present in GCC-8's -Wall -Wextra: Zero. None. Nada. Zilch. Mind you, I did have reports of some other compiler (mostly MSVC, but Clang with -Weverything as well) complaining about various weird things, including stuff like using bitwise operations on signed integers, or negation on an unsigned integer. They never lead to the discovery of an actual bug. On the other hand, one very important thing I did was using sanitizers extensively. ASan, MSan, UBSan, Valgrind, even the TIS interpreter (and now TIS CI), so I could weed out as much undefined behaviour as I could. And boy did those tools find actual bugs. Those, coupled with a proper test suite, will find all the bugs. The bugs I failed to find in time can all be traced with either not using the strictest runtime sanitiser, or a hole in the test suite. That being said, I still try very hard to be warning-free for most compilers out there. And I mostly am. But this is not about bugs. This is about sparing my users the headache that comes with investigating some trivial warning they should not care about. Monocypher does not need -Werror. [1]: I'm joking, he actually didn't.

UncleMeat 5y ago
All advice has exceptions. But I don't think it would be controversial to say that in most engineering organizations, -Werror will catch and prevent real bugs at a nontrivial rate.
- loup-vaillant 5y ago
  I strongly suspect the reason is because they tolerate incomplete test suite, and don't use sanitisers enough, despite their use of an insanely unsafe language (one thing I absolutely hate about C is the sheer amount of undefined behaviour). -Werror is just a stop gap desperate measure for when devs are pressured to write crap as quickly as possible. What's exceptional about Monocypher is not really that it's a cryptographic library (though that helps, modern cryptographic code tends to have pathologically simple control flow), it's that I took the time to polish it. That being said, I am not against static analysis. On the contrary, I am huge fan of strong static type systems, and for languages like C a static analyser can be a huge help. I also trust John Carmack when he says running a static analyser has found non-trivial bugs in real code. But then I want real static analysis, that can assess actual risks of making mistakes. Compilers need to be fast, so their warnings naturally tend to be crude. And if they start complaining about stuff like whitespace in a language where whitespace has no semantics, that may hurt more than it helps.
  - UncleMeat 5y ago
    "Just write good code" is not a workable plan for most organizations of any size. You often want workflows that are resistant to "we promoted somebody to TL when they shouldn't have been and they are not doing a very good job" situations. Yes, it is outrageous that anybody still writes programs in C or C++, which basically guarantee that you'll write oodles of subtle bugs. Yes, static analysis that finds problems that you can't train humans to find is more interesting. Yes, sanitizers and fuzzing should be mandatory for any serious project in C or C++. But "hey, you've got a vacuously true branch predicate" is valuable in a large number of cases even if humans can catch that with tests, since most organizations are not able to successfully hire only excellent engineers and give them sufficient time to never be rushed. Just a few weeks ago Google shipped a branch condition that included & rather than && that broke all Chromebook logins. I submit this as evidence that it it not possible to construct a large organization that is resistant to bad code without automation. Yes, a lot of other things needed to go wrong to enable this code to reach production but so many of those processes are either done by humans (and therefore error prone) or produce the same complaints when mandated by automation (e.g., 100% line coverage).

nullc 5y ago

A warning being thrown for a user which is caused by a bug that leads to mysterious crashes in a codebase which is warning free for the developer is something which is almost unobservably rare. So sure, a user getting a failed compile is superior to a mysterious crash, but that isn't the actual tradeoff in practice. Instead, if you have a post compile test suite which covers extensively all branches in the code you will catch things like miscompilation that warnings have little chance of catching. And well constructed the tests can have a zero rate of false positives-- which isn't something you'll get from warnings. So another choice: take the time you'd spend on the sisyphean task of dealing with random failures due to Werror new/old/different toolchains and invest it on making better post compile tests and save the Werror for your CI where its time wastage is more proportional to the benefit it provides.

slavik81 5y ago

> Which is an advantage. If the compiler issues a warning that triggers your -Werror then your code may contain bugs. Even if the compiler doesn't issue a warning that triggers -Werror, your code may contain bugs. This is the root of the false dichotomy you present.