[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: env+nice, one bug fix, two test corrections

From: Jim Meyering
Subject: Re: env+nice, one bug fix, two test corrections
Date: Wed, 28 Oct 2009 14:03:32 +0100

Eric Blake wrote:
> According to Jim Meyering on 10/26/2009 3:04 AM:
>>>From 501bf7b589e8c63c408c86fce5bb9902ae019017 Mon Sep 17 00:00:00 2001
>> From: Jim Meyering <address@hidden>
>> Date: Sat, 24 Oct 2009 13:50:13 +0200
>> Subject: [PATCH 1/3] nice: execute program even when setpriority fails due 
>> to EACCES
> I'm wondering if this also qualifies as a nice bug:
> $ nice -n -1 2>/dev/full nice
> 0
> $ echo $?
> 0
> The call to error() flushes stderr (so even if fd 2 is pointing to a file
> and stderr is not line-buffered, the error message is still output), but
> we are failing to check ferror(stderr), when we proceed to blindly invoke
> the subsidiary program even though we had a write failure.  Should we
> change the code to fail with EXIT_CANCELED if we detect failure to print
> the advisory message?

Good catch.

At first glance, this looked like a close call, but upon
reflection, it is clear that it does deserve a non-zero exit.
If we fail to diagnose the initial problem via stderr,
we have an obligation to escalate.  Failure to change
priority, for whatever reason, must be diagnosed.

reply via email to

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