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).
