[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: failure to build due to ignoring fwrite() result
From: |
Ludovic Courtès |
Subject: |
Re: failure to build due to ignoring fwrite() result |
Date: |
Wed, 01 Sep 2010 14:30:29 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) |
Hi Bruno,
FWIW I’d prefer more “neutral” wording, which couldn’t be interpreted as
discouraging use of static analysis tools, and at the same time try to
discuss trade-offs rather than taste:
Bruno Haible <address@hidden> writes:
> --- doc/standards.texi.orig Wed Sep 1 01:25:45 2010
> +++ doc/standards.texi Wed Sep 1 01:24:09 2010
[...]
> address@hidden clang
> address@hidden lint
> +Don't make the program ugly just to placate warnings from tools other
> +than those that you use on a daily basis. Extra GCC warnings options,
> address@hidden's static analysis facilities, and code style checkers like
> address@hidden can be valuable tools.
(Shouldn’t it refer to Splint since I think the historical Lint isn’t
free?)
> But if you try to placate too many
> +warnings, the readability of the code will deteriorate.
What about something like this?
However, placating warnings emitted by such tools should not be done
at the expense of readability and maintainability.
> For example,
> +you don't need to get rid of warnings produced by @samp{gcc -Wundef} or
> address@hidden -Wconversion} because these warnings rarely point to bugs.
And:
For example, it may sometimes be useless to get rid of warnings [...]
because these warnings are rather stylistic and rarely point to bugs.
Thanks,
Ludo’.
pgpRIeU1SLuHr.pgp
Description: PGP signature
- Re: failure to build due to ignoring fwrite() result,
Ludovic Courtès <=