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: Bruce Korb
Subject: Re: failure to build due to ignoring fwrite() result
Date: Mon, 30 Aug 2010 20:34:49 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100714 SUSE/3.0.6 Thunderbird/3.0.6

Hi,

On 08/30/10 18:24, Bruno Haible wrote:
> Hi Paul,
> 
>> + @pindex gcc
>>   @pindex lint
>> ! @pindex valgrind
>> ! Don't make the program ugly to placate @code{gcc -Wall}, @code{lint},
>> ! @code{valgrind}, or other software analysis tools.  These tools can
>> ! help find bugs, but they can also generate false alarms for constructs
>> ! that they incorrectly consider to be suspicious.  Although we want
>> ! useful warnings and don't want useless ones, we also want code that is
>> ! as readable as possible and is not cluttered with unnecessary casts or
>> ! wrappers.  For example, in C, please don't insert casts to @code{void}
>> ! or replace @code{0} with @code{NULL} merely to pacify a lint checker.
> 
> This proposed change does not describe today's common practice:
>   - "gcc -Wall" is useful for everyday work.[....]

This raises an interesting question to me: certain warnings triggered
by lint and gcc are very useful.  So, in general, you want them.
Unobtrusive annotations to tell a tool to just hush up do not uglify
the code enough to warrant a "please don't".  The ugly cost is far
exceeded by the tool benefit.  Perhaps a "try to avoid".

The utility of gcc's -Wall and lint analysis is degraded by false
positives that cannot be quieted.  In the particular case we are looking
at in excruciatingly long detail, the warning is normally quite useful.
We don't want to discard all such warnings with a --no-warn-whatever.
Since GCC does not parse commentary annotations, a cast to void should
do the job very nicely, but it does not.  So, I raised the issue
on the gnulib list because it is here we make adjustments for tools
that make life difficult.

We have several issues that ought to all be addressed, and only
the last is relevant for this forum:

1.  GCC needs to relax the constraint that functions marked with
    warn-unused-result cause warnings when the result _is_ handled
    with a void cast.

2.  Given what GCC does, glibc is over the top in marking fwrite
    with warn-unused-result

3.  Given 1 & 2, gnulib should provide method for papering over
    this stuff so that all warn-unused-result warnings do not get
    squished in order to suppress the one we want to suppress.



reply via email to

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