Re: error and program_name

[Jim Meyering]

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?

[0] if openat changes the working directory and fails to return,
that is too serious.  Doing otherwise could result in data loss
or corruption.  Hence, the function must not return to the caller.
Fortunately, the work-around code is used on fewer and fewer systems
these days, and the circumstances in which the *at-function emulation
fails in such a catastrophic manner do not arise frequently.