[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: error and program_name
Re: error and program_name
Thu, 23 Dec 2010 09:51:18 +0100
Eric Blake wrote:
> On 12/22/2010 03:19 PM, Jim Meyering wrote:
>> Bruno Haible wrote:
>>> Ping? No one wants to solve this? It's a critical issue for libposix.
>>> Eric Blake wrote:
>>>> error() is not POSIX. Maybe the thing to do is figure out what in
>>>> libposix is dragging in error(), and work on breaking that dependency.
>>>> That way, a package using libposix then makes their own decision of
>>>> whether to supplement things with error() and program_name.
>>> I replied:
>>>> Very good point. The dependency comes from
>>>> openat --> openat-die --> error
>>>> Can you work on breaking this dependency? I mean, for example,
>>>> instead of directly calling openat_save_fail() and
>>>> openat_restore_fail(), go through a variable that contains two
>>>> function pointers, and have openat() and fdopendir() return an error code
>>>> if these function pointers are NULL. Like we do with
>>>> See also
>> Hi Bruno,
>> Perhaps I don't understand the proposal, but here is my reaction:
>> IMHO, those functions must never return in the unusual case for which
>> they now call error and then exit. The failures are too fundamental,
>> and we cannot require that all callers handle any new error code or
>> interpret existing error codes differently, can we?
> Perhaps the thing to do would be:
> The openat module has a function pointer openat_failed_handler,
> defaulting to NULL. If we get into the situation where we changed
> directories but can't return, then call any non-NULL handler, and resort
> to calling abort() if the handler returns or if it was NULL.
Good idea, but any application built upon libposix deserves better than
a bare "abort". Imagine running a libposix-using du in an unreadable
directory for which getcwd does not work -- it would simply abort because
it is incapable of recording the initial working directory. Users and
those handling bug reports would not be happy, and would rightly call it
a bug. So, it would be best to also print the usual diagnostic -- and
even the program name, when possible to do so without the global variable.
Sounds like I'd like a variant of the error module that does not use
the program_name global.
> The openat-die module then populates the openat_failed_handler with a
> function that uses error() rather than abort.
> That way, posix modules use just openat and don't drag in error(), but
> coreutils imports openat-die to get the nicer behavior than an abort()
> (that is, no change from current behavior).
Re: error and program_name, Bruce Korb, 2010/12/22
Re: error and program_name, Bruce Korb, 2010/12/30