[IPOL discuss] Software guidelines: C/C++ warnings

[Miguel Colom]

Thank you for your replies Nicolas and David.
It's true that in section 2.2 the -Werror turns the warnings into errors,
but this option is just a recommendation.

Nowhere in the guidelines the necessity of removing the warnings is
specified.

I agree that for some warnings it's better to keep the warning than
inserting #pragma's or tricking with the language syntax. But these, in my
opinion, are special cases.

What we're more likely to find are warnings due to common mistakes, like
signed/unsigned comparisons, varibles and functions with const and without
a "const", etc

I think that we should insert a line in the guidelines asking to remove
trivial warnings.

Best,
Miguel

> Miguel,
>
>> I've noticed that the IPOL software guidelines don't tell explicitly
>> anything about the compilation warnings.
>> It's implicit at section 2.2, where it says "IPOL authors should test
>> their C and C++ source code with the gcc compiler in strict compilation
>> mode before submitting it to IPOL.".
>
> It is more than implicit: the "strict compilation options" example
> given in the footnote from section 2.2 includes the "-Wall -Wextra
> -Werror" options, resulting in compilation error on any compiler warning.
>
>> I think that it should say that the code *must* compile without any
>> warning in the strict mode.
>
> I agree with you that, usually, compiler warnings are there for good
> reasons and they should not be ignored. But there are three reasons
> for not making that a strict requirement. The two first ones have
> already been given by David, I only give other examples.
>
> 1. Some warnings are only noisy, or useless, or the programmer can be
>    smarter than the compiler. It seems to be frequent with C++, but it
>    can happen in plain C too. For example, there is a warning option
>    for float numbers comparison, because safe float comparisons should
>    be performed +/- epsilon. But if you read a float given by the
>    program user on the command-line, there has been no reounding
>    operation, and you can safely check if it is >0 if you want
>    to. Avoiding warnings would make the code slower or more obscure.
>
> 2. The list of compiler warnings is always changing. One compiler will
>    be silent and another one will complain. Every compiler version
>    will introduce new warnings, especially with . We can not require
>    the code to be warning-free without specifying at least one
>    compiler and version, and this may even not be enough, because maybe
>    different binary distributions of the same compiler come with
>    different default options (Ubuntu adds "hardening" options).
>
> 3. If we require no warning with precise compiler settings, some
>    authors will simply add #pragma in their code to ask the compiler
>    to ignore the warnings. This is ugly and counter-productive. Eigen
>    does that a lot (no further comments...).
>
> I think that, unfortunately, no automated tool, rule or test will
> guarantee the software quality. So far, brains are required to
> evaluate a code, so I hope reviewers will test the code, compile it
> will strict options, and ask the authors to fix their code if they see
> no clear reason to keep the warnings. This could be added to the
> reviewer manual.
>
> --
> Nicolas LIMARE - CMLA - ENS Cachan
> http://www.cmla.ens-cachan.fr/~limare/
> IPOL - image processing on line
> http://www.ipol.im/
> _______________________________________________
> discuss mailing list
> discuss at list.ipol.im
> http://tools.ipol.im/mailman/listinfo/discuss