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

[Nicolas Limare]

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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://tools.ipol.im/mailman/archive/discuss/attachments/20120403/6db3ae71/attachment.pgp>