3 ms·

> because you've introduced a dependency on a specific compiler version No, if you get warnings, it means that your code is (and was already) wrong. And if you

> because you've introduced a dependency on a specific compiler version No, if you get warnings, it means that your code is (and was already) wrong. And if you wrote wrong code you already have an implicit dependency on your compiler version, as more recent versions with more advanced static analysis may turn a semi-harmless unrecognized UB as a very harmful recognized one (and thus warn). I had this case a few times already, see a simple repro : https://gcc.godbolt.org/z/jY69sas8K https://gcc.godbolt.org/z/jY69sas8K -Werror just makes this dependency explicit.

saagarjha 5y ago
> No, if you get warnings, it means that your code is (and was already) wrong. No, that's not right, otherwise they wouldn't be warnings. The whole point of them existing is the compiler trying to alert you of a suspicious construct, but it's not confident enough to be sure it's a bug. Sometimes I want to use assignment for its result–that's not a bug, it's just something that is often done accidentally.
- tialaramex 5y ago
  There's a big language problem here. It's not the whole of the issue, but it's certainly a big component. In C and C++ there are a huge number of things that are legal, and thus must not cause an error diagnostic (out of the box) - and yet are obviously not what anybody should do (and so a warning diagnostic is appropriate if the compiler can successfully diagnose them). You give the example of "sometimes I want to use assignment for its result". A better language outright forbids this. If you want the result, write that, if you want an assignment, write that, if you want both, write both so that it's clear what you intended, and let the optimiser turn your clear program into efficient machine code rather than trying to out-guess the machine. Ideally warnings would not be red flags. If warnings are stuff like "This variable's name start with a capital letter when that's contrary to standard style guides." or "You keep saying 15 in this program, have you considered just defining a constant instead for whatever 15 is?" then you're in a better place, but unfortunately in C the warning is more likely to be "99.99% of the time this code is a buffer overflow, so, you probably don't mean that" or "It looks like this does X doesn't it? But, it actually does nothing at all, and for complicated reasons we can't make it do X, so, I really hope you didn't mean X."
  - josefx 5y ago
    > but unfortunately in C the warning is more likely to be "99.99% of the time this code is a buffer overflow, so, you probably don't mean that" In my experience it is more likely that 0.01% of the time this signed to unsigned conversion (the one in the if block checking value ranges) can cause issues, please explicitly cast it to silence the warning.
  - saagarjha 5y ago
    FWIW I stand by my argument pretty much regardless of language. (Most newer languages lack static analysis to the extent that C/C++ do, partially because many of the things are hard errors, and partially because nobody has gotten around to them yet.)
- jcelerier 5y ago
  Did you even look at the link I sent ? The warnings kindly tell you about actual undefined behaviour that is 100% a bug, like what -Wstrict-aliasing or -Wreturn-type reports
  - saagarjha 5y ago
    Yeah, I did. What you wrote was almost certainly a mistake (although, it's not guaranteed: one can image a macro expanding to such a tautology). But this is far from a convincing argument that all warnings indicate mistakes.
    - jcelerier 5y ago
      This exact mistake used to be in e.g. Qt, KDE, and Chromium code. That shit causes real world damage !
asveikau 5y ago
Have you not seen a warning that appeared frivolous or you disagreed with? Or, as my sibling comment says, might be a harmful construct in some contexts but used correctly in your example? Further, the compilers are evolving entities written by mere mortals, with their own bugs, occasional poor decisions, and yes, chances to be corrected over time. If the compiler's authors decide a warning is too noisy and disable it in release X, but random linux distro still uses (X - 0.1), should you fix it for them...?
- jcelerier 5y ago
  > Have you not seen a warning that appeared frivolous or you disagreed with Sure, and I explicitly -Wno- them in that case. > Further, the compilers are evolving entities written by mere mortals, with their own bugs, occasional poor decisions, and yes, chances to be corrected over time. Yes, but it is still increasing the chances that someone makes a build of your software with code strongly broken due to UB - that is not a chance anyone should ever ever take
  - saagarjha 5y ago
    You take that chance daily by not prefixing your code with a construct that would make it fail compilation in any other compiler but your special one that solves all UB. You are writing C that other people will compile with their own compilers–sometimes they are going to miss UB, sometimes they'll catch UB that you miss.
josefx 5y ago
> No, if you get warnings, it means that your code is (and was already) wrong. I get dozens of warnings for unused variables, signed unsigned conversions (where the value range is API enforced), etc. . Long ago we had thousands of warnings and went through our code base just to get rid of them, I would be surprised if we fixed even one bug while doing that, most was just adding some verbose construct to be explicit about what was already happening. Warnings can be helpful, which is why I still have them enabled, but not everyone is.

saagarjha 5y ago

> No, if you get warnings, it means that your code is (and was already) wrong. No, that's not right, otherwise they wouldn't be warnings. The whole point of them existing is the compiler trying to alert you of a suspicious construct, but it's not confident enough to be sure it's a bug. Sometimes I want to use assignment for its result–that's not a bug, it's just something that is often done accidentally.

tialaramex 5y ago
There's a big language problem here. It's not the whole of the issue, but it's certainly a big component. In C and C++ there are a huge number of things that are legal, and thus must not cause an error diagnostic (out of the box) - and yet are obviously not what anybody should do (and so a warning diagnostic is appropriate if the compiler can successfully diagnose them). You give the example of "sometimes I want to use assignment for its result". A better language outright forbids this. If you want the result, write that, if you want an assignment, write that, if you want both, write both so that it's clear what you intended, and let the optimiser turn your clear program into efficient machine code rather than trying to out-guess the machine. Ideally warnings would not be red flags. If warnings are stuff like "This variable's name start with a capital letter when that's contrary to standard style guides." or "You keep saying 15 in this program, have you considered just defining a constant instead for whatever 15 is?" then you're in a better place, but unfortunately in C the warning is more likely to be "99.99% of the time this code is a buffer overflow, so, you probably don't mean that" or "It looks like this does X doesn't it? But, it actually does nothing at all, and for complicated reasons we can't make it do X, so, I really hope you didn't mean X."
- josefx 5y ago
  > but unfortunately in C the warning is more likely to be "99.99% of the time this code is a buffer overflow, so, you probably don't mean that" In my experience it is more likely that 0.01% of the time this signed to unsigned conversion (the one in the if block checking value ranges) can cause issues, please explicitly cast it to silence the warning.
- saagarjha 5y ago
  FWIW I stand by my argument pretty much regardless of language. (Most newer languages lack static analysis to the extent that C/C++ do, partially because many of the things are hard errors, and partially because nobody has gotten around to them yet.)
jcelerier 5y ago
Did you even look at the link I sent ? The warnings kindly tell you about actual undefined behaviour that is 100% a bug, like what -Wstrict-aliasing or -Wreturn-type reports
- saagarjha 5y ago
  Yeah, I did. What you wrote was almost certainly a mistake (although, it's not guaranteed: one can image a macro expanding to such a tautology). But this is far from a convincing argument that all warnings indicate mistakes.
  - jcelerier 5y ago
    This exact mistake used to be in e.g. Qt, KDE, and Chromium code. That shit causes real world damage !

asveikau 5y ago

Have you not seen a warning that appeared frivolous or you disagreed with? Or, as my sibling comment says, might be a harmful construct in some contexts but used correctly in your example? Further, the compilers are evolving entities written by mere mortals, with their own bugs, occasional poor decisions, and yes, chances to be corrected over time. If the compiler's authors decide a warning is too noisy and disable it in release X, but random linux distro still uses (X - 0.1), should you fix it for them...?

jcelerier 5y ago
> Have you not seen a warning that appeared frivolous or you disagreed with Sure, and I explicitly -Wno- them in that case. > Further, the compilers are evolving entities written by mere mortals, with their own bugs, occasional poor decisions, and yes, chances to be corrected over time. Yes, but it is still increasing the chances that someone makes a build of your software with code strongly broken due to UB - that is not a chance anyone should ever ever take
- saagarjha 5y ago
  You take that chance daily by not prefixing your code with a construct that would make it fail compilation in any other compiler but your special one that solves all UB. You are writing C that other people will compile with their own compilers–sometimes they are going to miss UB, sometimes they'll catch UB that you miss.

josefx 5y ago

> No, if you get warnings, it means that your code is (and was already) wrong. I get dozens of warnings for unused variables, signed unsigned conversions (where the value range is API enforced), etc. . Long ago we had thousands of warnings and went through our code base just to get rid of them, I would be surprised if we fixed even one bug while doing that, most was just adding some verbose construct to be explicit about what was already happening. Warnings can be helpful, which is why I still have them enabled, but not everyone is.