Re: failure to build due to ignoring fwrite() result

[Jim Meyering]

Bruce Korb wrote:
> Hi Jim,
>
> On Mon, Aug 30, 2010 at 9:26 AM, Jim Meyering <address@hidden> wrote:
>> I don't like the length of "ignore_value" either, but think of that
>> as a feature, not a problem.  It's more of an auto-regulator: If I'm
>> ignoring so many "important" return values that the "ignore_value"
>> uses impair readability, then I take that as an indication that I'm
>> doing something wrong.
>
> Theoretically, that sounds right.  In "real life" I develop a lot of
> daemon software
> on appliances that really cannot go down.  If some FILE* descriptor becomes
> error prone, I trigger some alert somewhere but I may as well keep trying
> because it might get better.  I can't just quit because I'm unhappy with some
> FILE* descriptor.  Maybe extend the prefix a bit:
>
>    void_fwrite()
>
> for example?  Or even:
>
>    ignore_value_fwrite()
>
> In any case, it is the wrapping of the function call that I see as 
> comprehension
> clutter.  Much more so than the length of the prefix.

Hi Bruce,

Can your daemon software really afford to totally ignore
write failure?  If you're ignoring fwrite's return value,
you can't even *detect* a write failure, much less act on it.

One case in which not reporting a write error makes sense is when
the error arises in failing to write to a log, and that (logging) is
the only way to indicate failure (i.e. in a daemon).  But not even
to detect it?  Hence never to report write error...  In what
circumstance can that be ok?

It might make discerning reviewers feel slightly safer if your daemon
were to *detect* the failure but explicitly do nothing, and say why in
a comment.  Then, you're no longer ignoring the return value.