Re: error and program_name

[Jim Meyering]

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
>>>>   fdopendir
>>>>
>>>> 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
>>>>   argp_program_version_hook
>>>>   error_print_progname
>>>>   obstack_alloc_failed_handler
>>>> See also
>>>>   c_stack_action
>>>>   install_sigpipe_die_handler
>>
>> 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[0],
>> 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).