https://github.com/zcoinofficial/zcoin/commit/0359bcb2ead7fe...

This indicates that the code in question is not covered by tests. I work on a database, for which correctness is paramount, so it's unnerving to see any code fixes not associated with test additions or changes. I would have thought that cryptocurrency had similar standards.

    test.cpp: In function ‘int main()’:
    test.cpp:13:11: warning: statement has no effect [-Wunused-value]
             a == b;
               ^

    if (condition);
        dothis();

    if (condition);

In C++ you can overload '==' to do anything you want, including things that have side effects[0]. Without deeper introspection into the code, it's tricky to check if it's an error or not.

[0] PS. Never do this!

-Werror, I'm not sure. During development and on CI systems it makes sense. But if you intend to ship source code, it's probably best left off. Other people might be using different compilers that emit warnings for things yours didn't. You don't want the build to fail for those people.

Actually, you do. That way those things will be fixed and hopefully your inclusion of their fixes is a well motivated PR away.

Switching -Werror off should be a decision made with great care and understanding of what's going on under the hood. If there are platform specific issues then people on those platforms will be the ones in the best position to determine if such a warning is actually an error or not.

Having compilation break for a user because of a spurious warning due to a different compiler (or different compiler version) would make it a lot more painful to maintain.

For instance I started maintaining an old C++ codebase that generates a bunch of warnings when build with a modern g++, code like this:

    #define M "toto"

    const char *s = "tata"M;

warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]

Is it helpful? Sure. It is worth breaking the build for anybody using a modern g++ until I manage to fix all occurrences and release a new version? I don't think so.

An other example is building code with -Wextra which warns you when some comparisons become "nops". For instance:

    int toto(int i) {

      if (i <= 0xffff)
        return 1;

      return 0;
    }

warning: comparison is always true due to limited range of data type

In my experience this particular warning is generally not a problem. On the other hand the following code:

    int i = 0xabcdef;

warning: integer constant is too large for its type

And that's potentially a lot nastier and should be an error IMO.

So I'd say the main problem is that C and C++ are way too permissive by default, things like comparison with no side effects ought to be errors, not warnings. And there are a bunch of others, for instance why on earth are these not errors :

    warning: no return statement in function returning non-void
    warning: ‘i’ is used uninitialized in this function

Surely this is a serious problem on 16 bit builds; the comparison implies that larger values are expected to be stored in this variable, the warning is a strong hint that the (size of the) types are incorrect.

This, a hundred times. Building without proper warnings (and without proper tests, review) is just bad engineering, and mediocre coding.

It seems that D never really got the love it deserved, perhaps because it didn't have a Google or Mozilla behind it.

I feel it is my duty as a language designer to make it hard for programmers to commit common bugs. It's just too expensive for companies to ship these kinds of things.

I'm guessing that this was meant to be a single equals sign for an assignment rather than a double equals for an equality test?

   --accept_my_buggy_stupid_code

I can't think of a reason any modern language should accept such code.

If you're interested, I recommend the series "Air Disasters" on TV. Each episode analyzes one crash, where investigators determine the cause of the accident, and what the corrective action should be taken. Often, it comes down to "how could a pilot with 10,000 hours experience make such a mistake". While it would be easy for investigators to blame the pilot, often they find that the mistake was just too easy to make, and they recommend changing the design or procedures or both.

[0] https://ideone.com/eJgiN9