httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: ap_status_t for Win32
Date Thu, 30 Mar 2000 15:41:31 GMT

> On Windows, ap_status_t sometimes contains GetLastError() values and
> sometimes contains errno values and sometimes contains APR-specific
> error codes (and maybe sometimes contains other types of error codes).
> (1) This means that the application is not currently able to get a
> description of the error for presentation to the user.  (2) It also means
> that the application is not able to compare it with particular error
> codes that it has logic to handle.

Yes, Windows is broken.  Sometime is returns errno, sometimes it returns
GetLastError values.  I posted where that needs to be fixed.  And, every
single time this needs to be fixed, there is already a TODO in the code.

> Example of the first problem: Currently, the text description returned
> by strerror() to ap_log_error() is almost always bogus on Windows because
> most errors passed around on Windows are from GetLastError().  We
> might as well put #ifndef WIN32 around the logic to describe the
> error, unless the use of ap_status_t is straightened out and
> ap_strerror() is subsequently implemented (it can't be implemented
> until it has a way to interpret ap_status_t).

That #ifdef was there, we took it out in ap_log_error().  Implement
ap_strerror, because currently all ap_strerror does is call strerror.  The
fault lies in this being an incomplete implementation, not a faulty
design.  Go read the design that happened on new-httpd when this stuff was
originally committed.

> Example of the second problem: Suppose an application calls
> ap_do_something_cool(), which returns the number 99 in the ap_status_t
> result.  In most places, the application just cares whether or not the
> result is APR_SUCCESS, but in this case, the application needs to know
> exactly what error occurred -- APR_EOF?  ENOSPC?
> ERROR_SERVER_NOT_RESPONDING? -- so that it can implement a specific
> recovery strategy.

For APR status or APR error codes, these values are specified in a header
file with both a name and a value.  For OS specific errors, we will need
to implement a function ap_canonical_error, which converts a SMALL subset
of error values to the Unix errno definition.

> Maybe I can't understand it because I see another philosophy being
> used in APR today and I assumed that it was basically correct.  

The windows port has never been finished in this regard.  The correct
implementation was discussed on new-httpd.

> Should I go delete all the APR_ constants in apr_errno.h, change all
> APR code to use only OS-specific error codes (that's errno on UNIX and
> GetLastError()-type error codes on Windows)?

Don't delete any defintions.  Go into apr_errno, and re-define all of the
APR_FOO macros for use on windows.  This should work just fine.


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

View raw message