Re: error and program_name

[Bruno Haible]

Hi Jim, Eric,

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

OK. Can the code for openat be adapted in such a way that only two
kinds of failures can occur:
  (a) Failures that can only be due to programming errors.
  (b) Failures that are harmless enough that the calling program
      can ignore the error and continue nevertheless.

Failures of type (a) can be handled with abort(). Failures of type (b)
can be communicated through an error code.

For example, if save_cwd called
  currdir_fd = open (".");
then on a platform that supports fchdir() natively [not gnulib's
emulation], a failure to do  fchdir (currdir_fd)  is of type (a).
It can only occur if some other part of the program did side
effects on currdir_fd.

And when open (".") failed, or the platform does not support
fchdir() natively, then there is no safe way to get back to the
previous current directory using chdir(), because directories
might be renamed while the program is running. In such a situation,
I think a library function should not change the current directory -
and instead use concatenations of absolute and relative file names
instead. Yes, there may be a couple of situations where such a
"safe" openat() cannot do things that the current adventurous
openat() can do; in that case, let it fail with EPERM, ENAMETOOLONG,
or whatever error number is appropriate.

Yes, in the code we may have to distinguish between a "safe"
openat() and an adventurous one. I think that's part of the job
of librarifying the openat() code.

Bruno