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 Mon, 29 May 2000 14:59:11 GMT

> >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?  As
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.  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.

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.


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

View raw message