httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: ap_status_t for Win32
Date Thu, 30 Mar 2000 12:02:08 GMT
> > Other than Windows errors, the other types of errors we must support
> > on Windows are:
> >
> > . errnos set by C run-time library
> > . portable APR error codes like APR_ENOPOOL and status codes like
> >   APR_EOF
> > . error codes from other libraries such as those from libtool
> PLUS - app specific error extensions (give them a pool of n
> numbers).

fine with me, but as far as I'm concerned, "app specific error
extensions" are a part of the "error codes from other libraries"
problem; an arbitrary number of other libraries could be used with
APR, and app errors are sort of in the same boat

> > For Windows, this implementation of Bill Rowe's desired
> > classification/manipulation macros would seem to work:
> >
> > /* use bits 31-30 to indicate which type of non-Windows error it
> >    is; bit 29 is on for any non-Windows errors */
> >
> > #define APR_ERRORTYPE_MASK  0xE0000000
> >
> > #define APR_ERRORTYPE_OS    0x00000000
> > #define APR_ERRORTYPE_ERRNO 0x20000000
> > #define APR_ERRORTYPE_APR   0xA0000000
> > (room for two more types with this value of APR_ERRORTYPE_MASK; we can
> > always steal more lower-order bits in the future)
> I wouldn't mess with the top 2 bits - leave them alone (40, 80, C0).

What is special about the top two bits?  To me, that helps stay as far
away as possible as the bits that other libraries will want to use for
their own purposes.

> If you like suggestions for win32... using the facility to clarify,
>  0x00000000 (no bit 29) would be windows
>  0x20000000 would be good for clib
>  0x20010000 would be good for apr
>  0x20020000... for apps (multiple, perhaps?)

There is no difference between this and what I had, other than that
you use the term "facility" and I didn't, and that I put them in a
higher-order range where they are less likely to collide with error
codes from other packages. 

> > UNIX is similar, though there is no requirement for bit 29 and no
> > separate OS error, since OS errors are errnos.  APR_STATUS_IS_OS()
> > would always return 0 (false).
> True enough of APR_STATUS_IS_OS.  This should be a _simple_ case
> for illustration, start here.  Don't confuse everyone with the Win32
> implementation details yet.

I'm not going to start with a UNIX-only implementation first, commit
it, and then start worrying about Win32.  Win32 is the platform with
the biggest problem now.  (Maybe OS/2 and BeOS as well, but I don't really
know.)  If somebody wants to do an implementation that handles only
the simple case, go right ahead.  I was interested in an initial
implementation that handled UNIX and Win32, in the hopes that if it
handled those two then to add support for some other platform would
not require much reinvention.  Also, I personally have not been
frustrated with ap_status_t descriptions on UNIX (the current
strerror() code works most of the time) but I do on Win32 (most of the
time the error string is bogus).  Without a solution for my itch,
there is no reason for me to scratch.  Sorry!

> No... ap_strerror() is portable only in it's declaration.  It is _NOT_
> portable in it's implementation.

I have tried to explain in previous notes how much of it is portable.
Your use of upper case does not help me to come to agreement.
Explaining *why* a particular statement I am making is wrong does.
Start with the statements below and help me out.  

Only one small part of ap_strerror() is not portable: the mechanism
for retrieving the description of an OS-specific error.

Summary of portability:

  portable parts of the ap_strerror()

  . code to identify that error is errno
  . code to grab description for an errno
  . code to identify that error is APR error/status code
  . code to grab description for an APR error/status code
  . code to identify that error is OS-specific error code
  . code to handle other types of error codes

  non-portable parts of ap_strerror()

  . code to grab description for an OS-specific error code

Clearly, ap_strerror() is largely (85%?) portable.  It just needs a
service routine implemented for each platform to retrieve the
description for an OS-specific error code.

The implementations of the macros to manipulate ap_status_t are
definitely unique to each OS, but that is outside of the scope of

Jeff Trawick | | PGP public key at web site:
          Born in Roswell... married an alien...

View raw message