[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: failure to build due to ignoring fwrite() result
From: |
Jim Meyering |
Subject: |
Re: failure to build due to ignoring fwrite() result |
Date: |
Mon, 30 Aug 2010 21:59:54 +0200 |
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)))
- Re: failure to build due to ignoring fwrite() result, Bruce Korb, 2010/08/30
- Re: failure to build due to ignoring fwrite() result, Eric Blake, 2010/08/30
- Re: failure to build due to ignoring fwrite() result, Bruce Korb, 2010/08/30
- Re: failure to build due to ignoring fwrite() result, Jim Meyering, 2010/08/30
- Re: failure to build due to ignoring fwrite() result, Bruce Korb, 2010/08/30
- Re: failure to build due to ignoring fwrite() result, Jim Meyering, 2010/08/30
- Re: failure to build due to ignoring fwrite() result, Bruce Korb, 2010/08/30
- Re: failure to build due to ignoring fwrite() result,
Jim Meyering <=
- Re: failure to build due to ignoring fwrite() result, Eric Blake, 2010/08/30
- Re: failure to build due to ignoring fwrite() result, Jim Meyering, 2010/08/30
Re: failure to build due to ignoring fwrite() result, Paul Eggert, 2010/08/30
- Re: failure to build due to ignoring fwrite() result, Ralf Wildenhues, 2010/08/30
- Re: failure to build due to ignoring fwrite() result, Jim Meyering, 2010/08/30
- Re: failure to build due to ignoring fwrite() result, Bruce Korb, 2010/08/30
- Re: failure to build due to ignoring fwrite() result, Eric Blake, 2010/08/30
- Re: failure to build due to ignoring fwrite() result, Eric Blake, 2010/08/30
- Re: failure to build due to ignoring fwrite() result, Jim Meyering, 2010/08/30
Re: failure to build due to ignoring fwrite() result, Eric Blake, 2010/08/30