apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Kraemer <mar...@apache.org>
Subject APU_DBD_DRIVER_FMT should be private
Date Fri, 06 Jul 2007 07:41:14 GMT
Hi everyone,

In the discussion around the error reporting of dlopen() errors when
loading APR database drivers, I have understood that

* currently, only the fact that a driver failed to load can be
  reported back to the caller

* the caller gets APR_EDSOOPEN when dynamic loading failed, but no clue
  about the name of the file which caused the error.

At the moment, APU_DBD_DRIVER_FMT describes the format that is used
internally in apr_dbd.c to build the name of the shared object, from
the value of the APU_DSO_LIBDIR macro (which is apu-private from
apr-util/include/private/apu_config.h) and the name of the driver,
by using:
  #define APU_DBD_DRIVER_FMT  APU_DSO_LIBDIR "/apr_dbd_%s.so"
  apr_snprintf(path, sizeof path, APU_DBD_DRIVER_FMT, name);

  This is going to break badly if APR is installed into a directory
  that is called, say,
  because then the two %s are both interpreted as string expansion
  format chars, and apr will probably dump core.

     #define APU_DBD_DRIVER_FMT "%s/apr_dbd_%s.so"
     apr_snprintf(path, sizeof path, APU_DBD_DRIVER_FMT, APU_DSO_LIBDIR, name);
  this should protect against directories with '%' characters.

2) the APU_DBD_DRIVER_FMT should IMO not be public at all, but
  should be even more local (local to apr_dbd.c) -- its usage semantics
  are highly specific to apr_dbd.c

3) For finding out the name that caused dynamic loading to fail, the
   interface of the function doing the loading --apr_dbd_get_driver()--
   should either be extended to allow for returning the absolute path
   of the failing shared lib,
   or a new function should be added that returns the name of the
   shared object in question, when given the same driver name as
   apr_dbd_get_driver(), something like

    /* Get the absolute path of the driver's shared object */
    apr_status_t apr_dbd_get_driver_dso_path(apr_pool_t *pool,
                                       const char *name,
                                       char **returned_name);

   that fails with APR_ENOTIMPL if !defined(APU_DSO_BUILD)

What do you think?

<Martin.Kraemer@Fujitsu-Siemens.com>        |     Fujitsu Siemens
http://www.fujitsu-siemens.com/imprint.html | 81730  Munich,  Germany

View raw message