httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Havard" <>
Subject Re: cvs commit: apache-2.0/src/lib/apr/misc/unix errorcodes.c
Date Mon, 29 May 2000 15:34:19 GMT
On Mon, 29 May 2000 07:59:11 -0700 (PDT), wrote:

>> >I'll change the API tonight to try to make it more useful for OS/2
>> >tonight.  If I make the wrong API change, please fix it.
>> Well, by itself what you've done doesn't really help any and, as OtherBill 
>> pointed out, is invalid due to the non-static buffer.
>> I tend to aggree with this. Here's what I'd like to do. I know you want to use 
>> ap_strerror() for everything but that restricts error messages to those that 
>> can be derived purely from ap_status_t unless you use hacks like global 
>> variables. I don't see the harm in having a special dso aware version of 
>> ap_strerror() if ap_strerror() still works.
>Please give an example of where the current system isn't good enough?

OS/2's DosLoadModule() returns the name of the module that failed to load,
a potentially valuable piece of information when there's a complex tree of
module dependencies. In v1.3 this is provided in the OS/2 ap_os_dso_error()

>far as I can tell dso's are working on all platforms with good error
>messages.  If I am wrong about that, please let me know.

That's probably true, but they could be better. What I'm saying is that in
its present form ap_dso_error() is nothing but a renamed dlerror() and as
such is useless and should either be made useful or go away. The patch I
provided shows one way of making it useful without making ap_strerror() any
less useful.

>What I think is
>being missed here, is that APR_EDSOOPEN is the only error value returned
>because it is the only one needed right now.  If a platform requires two
>or three different error codes, then they should be added.  This allows
>ap_status_t to handle all error codes effectively.

It's not being missed. The only time APR_EDSOOPEN is being used at all is
when dlopen() returns no useful error code, so this is also the only time
ap_dso_error() is ever called. This is why ap_dso_error() is nothing but a
renamed dlerror().

>I really strongly dislike having a second error string reporting
>function.  I think we can work around this in other ways.  Once we start
>adding error reporting functions for one APR type, we open the door for
>all types.  It is a minor jump for a new platform to say "We need an error
>reporter for File I/O or network I/O.  I want to fix this within the
>current mechanism, because I truly believe it is possible.

I don't see why it's bad as long as ap_strerror() isn't degraded at all.

 |  Brian Havard                 |  "He is not the messiah!                   |
 |  |  He's a very naughty boy!" - Life of Brian |

View raw message