Ignoring failures and altering behavior

[Florian Weimer <fweimer at redhat dot com>]

In many cases, glibc currently papers over resource allocation failures
by changing behavior.  Some examples:

* If we cannot load a NSS service module with dlopen for any reason
  (including malloc/mmap failures), we pretend that the service module
  does not exist.  NSS will possibly return different data as a result.

* If we cannot allocate memory for the gconv/iconv path, we will ignore
  the user configuration and use a built-in path.

* If we cannot open /etc/host.conf for any reason, we do not report an
  error and pretend that the file does not exist, possibly altering
  name resolution results.

* If we get a read error indicating file system corruption or
  unavailability for a directory in the dynamic linker, we ignore that
  directory.

I'm sure there are many more examples.

File system errors can be quite tricky.  I used this code in one case to
tell persistent, possibly intended errors from actual problems:

  FILE *fp = fopen (_PATH_RESCONF, "rce");
  if (fp == NULL)
    switch (errno)
      {
      case EACCES:
      case EISDIR:
      case ELOOP:
      case ENOENT:
      case ENOTDIR:
      case EPERM:
        /* Ignore these errors.  They are persistent errors caused
           by file system contents.  */
        break;
      default:
        /* Other errors refer to resource allocation problems and
           need to be handled by the application.  */
        return NULL;
      }

But I think there is a larger question here: Should we keep running at
all cost, possibly giving quite different results, or is it better to
actually report the errors we encounter and stop?

Thanks,
Florian