Joe Orton wrote: > On Tue, Jun 20, 2006 at 02:11:37PM -0700, Justin Erenkrantz wrote: >> On 6/20/06, david reid <[EMAIL PROTECTED]> wrote: >>> I'd like to commit this patch which adds an APR_ESSL error to APR. It's >>> only use will be in the ssl code now in apr-util. Is this the right >>> place for it? >> Since the SSL code lives in apr-util, then I think the error code >> definition belongs in apr-util not apr. The way the LDAP errors work >> is probably a halfway-decent guide. -- justin > > The key to solving this properly is to abstract away the underlying > error codes returned by the toolkit being wrapped - the LDAP code
Agreed. I plan on trying to do this, but also agree with Graham that there must be a way to get the *raw* error code from the library. Whether that will be useful isn't something a library should decide :-) In the same vein, maybe have a function to return the "type" of library being used? apr_ssl_library_name() or some such? > doesn't do that, it just dumps the LDAP_* errors in a structure (and > hence PR 39529). > > If the aim is to actually abstract away the SSL toolkit then you need to > work out exactly what error codes need to be returned and where (i.e. > have a well-defined API), then define new errors in apr-util in the > _USERERR space and map these from the toolkit used. (it's a pity there > wasn't an error code space reserved for apr-util in apr_errno.h; that > would be useful to fix in APR 2.0) A good idea. I'll look at adding some error codes to apr-util later. david
