httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <trawi...@bellsouth.net>
Subject Re: DSO Patch 1 of 3 (+ commentary!)
Date Wed, 29 Mar 2000 19:18:37 GMT
> Windows uses all 32 bits to tag errors, therefore the +-OFFSET
> fix really isn't portable to windows.  

I looked in the win32 error header file and found values up to 4000 or
so.  I didn't realize that there were values much higher.  Where is a
description of other sorts of error codes, or what do I look at to
understand when Win32 returns other error codes?

> Windows would be better off with facility codes (the mask for
> the facility code is &1FFF0000) to reflect the error was in
> Apache or APR, clib or the OS.  

Who uses these facility codes now?  If we get to play with those
particular bits to indicate the type of error, that means that Windows
doesn't use all 32 bits, right?  But that contradicts the first point
above.  Is it fair to say that Windows defines the concept of facility
codes for the app to use, but specifies all zeros for the facility
itself?

Flipping on particular high order bits is fine with me.  Note that it
is essentially the same as the existing APR design which I thought I
was using, except that the offset is a particular combination of
powers of two rather than a number which decimal-friendly.  The
offsets you suggest are nicer of course because of the cleaner
mechanism of determining what type of error it is -- testing a
particular bit.

> Seems Ryan is correct here, with a twist.  I would localize the
> error wrapper to the platform, like Ryan, but I would at least
> add APR_STATUS_IS_ERRNO(), APR_STATUS_IS_APR(), APR_STATUS_IS_OS(),
> APR_STATUS_IS_APP, etc...  create transform macros such as
> APR_STATUS_OF_ERRNO() or APR_ERRNO_OF_STATUS(), and allow the apr's
> platform designers to map the OS errors based on the platform.

I guess I haven't had enough caffeine today.  I think you and I are
both talking about a way to store two things in ap_status_t:

1) an error code
   . this could be an OS-specific primary error code like what
     GetLastError() returns or like what OS/2's APIs return
   . this could be an errno
   . this could be one of the "portable" APR error codes like
     APR_ENOPOOL

   Please help me out here.  Does anybody disagree with this point?

2) an indicator of which type of error code it was

   I used what I thought was the existing APR design to do that -- the
   constants like APR_OS_START_SYSERR in apr_errno.h.

   Bill R. used much, much nicer offsets which enabled the twiddling
   of certain high-order bits.

> Of course, I don't object to errors 0...4192 being soley allocated
> to the standard clib.  It would still be nice if APR would expose 
> an ap_fmterror() of any ERRNO, APR, or OS error.  Leave the actual
> disposition of and formatting of app errors to the app.

Isn't this exactly what ap_strerror() as presented does?  It doesn't
force the app to know what type of error it is.  It simply promises to
give a description for any type of error code that APR can return.
What the app does with it (e.g., record it in the trace) is of no
concern to ap_strerror(). 

Thanks for your time,

Jeff
-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...

Mime
View raw message