Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Message-Id: <200005291534.BAA19692@silk.apana.org.au>
From: "Brian Havard" <brianh@kheldar.apana.org.au>
To: "new-httpd@apache.org" <new-httpd@apache.org>
Date: Tue, 30 May 2000 01:34:19 +1000 (EST)
Reply-To: "Brian Havard" <brianh@kheldar.apana.org.au>
Priority: Normal
In-Reply-To: <Pine.LNX.4.21.0005290745470.3972-100000@koj.rkbloom.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: cvs commit: apache-2.0/src/lib/apr/misc/unix errorcodes.c

On Mon, 29 May 2000 07:59:11 -0700 (PDT), rbb@covalent.net 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()
function.


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

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!                   |
 |  brianh@kheldar.apana.org.au  |  He's a very naughty boy!" - Life of Brian |
 ------------------------------------------------------------------------------