Compile warnings

Compile warnings

[Frans Klaver]

Hi,

Every now and then I see an 'unused result' warning come by during  
building. What is the general attitude towards these warnings? Remove them  
(by properly checking)? Or leave them be as a kind of documentation -- we  
know we're ignoring the info, but it's good to be reminded?

Thanks,
Frans

Re: Compile warnings

[Ævar Arnfjörð Bjarmason]

On Mon, Nov 14, 2011 at 15:55, Frans Klaver <fransklaver@gmail.com> wrote:
> Every now and then I see an 'unused result' warning come by during building.
> What is the general attitude towards these warnings? Remove them (by
> properly checking)? Or leave them be as a kind of documentation -- we know
> we're ignoring the info, but it's good to be reminded?

Under what OS / version and compiler / version and what's the warning?
Paste the full warning(s) you get verbatim.

Re: Compile warnings

[Frans Klaver]

On Mon, 14 Nov 2011 17:58:20 +0100, Ævar Arnfjörð Bjarmason  
<avarab@gmail.com> wrote:

> On Mon, Nov 14, 2011 at 15:55, Frans Klaver <fransklaver@gmail.com>  
> wrote:
>> Every now and then I see an 'unused result' warning come by during  
>> building.
>> What is the general attitude towards these warnings? Remove them (by
>> properly checking)? Or leave them be as a kind of documentation -- we  
>> know
>> we're ignoring the info, but it's good to be reminded?
>
> Under what OS / version and compiler / version and what's the warning?
> Paste the full warning(s) you get verbatim.

This question was triggered by

     warning: ignoring return value of ‘fwrite’, declared with attribute  
warn_unused_result

appearing in diff.c, graph.c, grep.c and several others. I'm using gentoo  
linux, gcc 4.5.3.

So the specific question would be, do these fwrites need to be checked?

Re: Compile warnings

[Junio C Hamano]

"Frans Klaver" <fransklaver@gmail.com> writes:

> Every now and then I see an 'unused result' warning come by during
> building. What is the general attitude towards these warnings? Remove
> them  (by properly checking)? Or leave them be as a kind of
> documentation -- we  know we're ignoring the info, but it's good to be
> reminded?

A callsite of a function whose return value is better checked should be
checked (e.g. not checking return from close(2) or write(2) in a non-error
codepath), but there is no strong mechanical "General attitude".

Sprinkling (void) that casts the return values all over the place makes
our code illegible, and we do not prefer it as a solution. A function
that returns a value that is useful for some callers but can be safely
ignored by others is sometimes an indication of a poor API, and for our
own code, we tend to prefer designing the API to pass optional pointer
to return value from callers that do want to use the return value (and
others that do not care about the return value pass NULL).