bug-gnulib
[Top][All Lists]
Advanced

[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’.

Attachment: pgpRIeU1SLuHr.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]