httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@lnd.com>
Subject RE: cvs commit: apache-2.0/src/lib/apr/misc/unix errorcodes.c
Date Mon, 29 May 2000 04:10:39 GMT
> -----Original Message-----
> From: rbb@locus.apache.org [mailto:rbb@locus.apache.org]
> Sent: Sunday, May 28, 2000 9:19 PM
> To: apache-2.0-cvs@apache.org
> Subject: cvs commit: apache-2.0/src/lib/apr/misc/unix errorcodes.c
> 
> 
> rbb         00/05/28 19:18:45
> 
>   Modified:    src/lib/apr/dso/os2 dso.c
>                src/lib/apr/dso/unix dso.c
>                src/lib/apr/dso/win32 dso.c
>                src/lib/apr/include apr_dso.h
>                src/lib/apr/misc/unix errorcodes.c
>   Log:
>   Update the ap_dso_error API to work with other platforms.
>   
>   1.18      +2 -1      apache-2.0/src/lib/apr/misc/unix/errorcodes.c
>   
>   Index: errorcodes.c
>   ===================================================================
>   RCS file: /home/cvs/apache-2.0/src/lib/apr/misc/unix/errorcodes.c,v
>   retrieving revision 1.17
>   retrieving revision 1.18
>   diff -u -r1.17 -r1.18
>   --- errorcodes.c	2000/05/27 21:40:18	1.17
>   +++ errorcodes.c	2000/05/29 02:18:44	1.18
>   @@ -74,6 +74,7 @@
>    
>    static char *apr_error_string(ap_status_t statcode)
>    {
>   +    char buf[256];
>        switch (statcode) {
>        case APR_ENOPOOL:
>            return "A new pool could not be created.";
>   @@ -102,7 +103,7 @@
>        case APR_ENOSHMAVAIL:
>            return "No shared memory is currently available";
>        case APR_EDSOOPEN:
>   -        return ap_dso_error();
>   +        return ap_dso_error(buf, sizeof(buf), APR_EDSOOPEN);
>        case APR_INCHILD:
>            return
>    	    "Your code just forked, and you are currently 
> executing in the "

If you mean to allow the ap_dso_error call to return it's result
in buf, we just off the result from the stack frame :-)

If you didn't, it's redundant, the platform can make a buf if
it plans to do anything with it.

I respectfully suggest that this is a classic case where an #IFDEF
is entirely in order, and that ap_dso_error() should go away.
dlerror() was just fine.  I'd suggest a simple
#define HAVE_DLERROR
and include this only if we are building the stock unix dso support 
into apr (as opposed to the linux build Jeff(?) was playing with).

Ya know... it's never the big patches that kill you, it's those
little pesky ones :-)

Mime
View raw message