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

[Jim Meyering]

Bruce Korb wrote:
> On Mon, Aug 30, 2010 at 9:59 AM, Jim Meyering <address@hidden> wrote:
>> 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.
>
> Writing status to a private (not-syslog) file.  If there's a problem,
> someone ought to be informed.  As mentioned various places,
> checking the return of fwrite won't ensure you've captured a problem.
> If you catch something, you have some problem, but if you have
> a problem, you won't necessarily catch it.  So you have to fflush
> and then check error status.  And then emit an event.  (That works,
> or the system falls over.)  If there were an error at one log point
> that wasn't noticed, it'd get caught within a second or two anyway.
> Nobody's going to initiate a manual intervention within seconds
> anyway.  So, the probability of missing a problem for "too long"
> is sufficiently close to zero that it isn't worth worrying over at every
> opportunity (every fwrite call).
>
> The particular code in question was not a daemon, but my autogen
> thingey.  The code in question emitted a shell script.  If the output
> is cut short, the user needs to figure out why, but I ought to check
> ferror when I'm all done.  In this context, I'd have used xfwrite()
> instead of explicitly casting it to void.
>
>> 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?
>
> As I said, checking ferror() at the end of a write-to-log session then
> triggering an event.  "good enough" even if not excruciatingly perfect.

Checking ferror is good enough as long as you rely only on fwrite, and
not say, *printf.  Some *printf failures are specified as not detectable
via ferror (but of course, the standard does not say that outright).

> Anyway, even ignore_value_fwrite() is a readability win over
> ignore_value(fwrite()), but I'd prefer either void_fwrite() or yfwrite()  --
> but I'm now leaning more toward void_fwrite() at this point.

#define void_fwrite(a, b, c, d) (ignore_value (fwrite (a, b, c, d)))