httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: cvs commit: apache-2.0/src/lib/apr/misc/unix errorcodes.c
Date Sat, 27 May 2000 16:37:11 GMT

> I don't really like this. It may make sense when using dl but as someone
> else pointed out, dl is only one of many possible module loading APIs.
> Because ap_dso_error() takes no parameters it has to rely entirely on
> global data which has got to be bad in a multithreading library. If you
> need to construct the string in ap_dso_error() it also forces you to return
> a global buffer. Bleugh!
> My proposal:
> 1) ap_dso_load() should always return the OS error code associated with the
> failure. If there isn't one I guess AP_EDSOLOAD will have to do.

This is exactly what is currently happening

> 2) ap_dso_error() should take an ap_dso_handle_t which can have error
> details stored in it. It should also take a buffer & buflen like
> ap_strerror() does to avoid memory leakage/static buffers.

I committed what works on Unix.  If the API needs to change, change it to
work on OS/2.  I don't have an OS/2 machine nearby to know what OS/2

> 3) The application calls ap_dso_error() with the failed ap_dso_handle_t
> instead of ap_strerror(). ap_strerror() will just say something like "DSO
> load failed" if it gets passed AP_EDSOLOAD.

No.  We are trying to keep error handling consistent.  This breaks that
consistency completely.

> Of course the downside is that the application has to use a different
> function to get the best error message but I think it's worth it given that
> some platforms have useful string information associated with a module load
> failure.

And that information can be retrieved with the current code.  Just change
the API if a platform needs to get a buffer returned from ap_dso_error.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message