httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: cvs commit: apache-2.0/src/lib/apr/include apr_errno.h
Date Wed, 05 Apr 2000 14:49:47 GMT
On Wed, 5 Apr 2000, Jeff Trawick wrote:

> > -1 because of this patch and the description you posted earlier.
> What is the relationship between this change and the part of the
> APRDesign patch which you objected to?  I don't see any connection.

You posted an doc change for how to report errors in APR, and a code
change for how errors are done in APR, and don't see a connection between

> Other requirements I heard voiced were:
> . use the same value for offset on all platforms

I thoroughly disagree with this requirement and I have said so multiple
times in the past.  It is unfeasable.  We have already been told that on
Windows and non-windows error code should have bit 29 marked.  This code
doesn't do that.

Are we going to specify that ALL platforms need to have bit 29 marked for
non-OS error codes?

> . be able to encode any possible Win32 error
> These requirements all sound cool to me, but clearly not all of these
> requirements can be met simultaneously so realizing that I need to get
> on with things I chose a number.  There is hardly a big cost to
> changing that number later.  I don't see why you're so excited.

I am not excited.  I asked for clarification of where things were headed.
This is a common request around here.  :-)  I gave it a -1 until I
understand where things are going, because I don't currently.

> > I would like to see a VERY clear explanation of where this is going.  
> Where is this going?  This is to allow an OS-specific error code to be
> stored in an ap_status_t in a manner that the caller of an APR
> function can determine, if they so choose, what the heck they got
> back.  It takes into consideration the fact that certain systems use
> values for their return codes that collide with errno values and APR
> error/status values.  That is the truth, the whole truth, and nothing
> but the truth.  Look at the patch.  There isn't anything else there.

But what you are doing, AFAICT, is requiring that each platform returns
the same value when there is an error.  I strongly disagree with this
idea.  It requires that all platfroms convert from a native error code to
an APR code whenever there is an error, and then convert back when they
want to report that error as a text string.

As I have stated many times in the past, most of the time when there is an
error, the programmer just wants to know there is an error, not which
error it was.  If the programmer wants to know which error they received,
they will have to call another function.  This puts to onus on the
programmer to do the conversion, which is where it belongs because the
programmer understands what he is doing.

> > be honest, what scares me the most is that we are using the same values on
> > every system.
> Tell me a system which has APR OS-specific code which calls
> OS-specific functions and stores them in ap_status_t where this
> doesn't work.  (Hint: Win32 *might* could theoretically return values
> that won't work, but I sort of doubt that it is possible today given
> the types of Windows calls used by APR.  Besides I didn't see a lot
> of consensus for a solution which handled any possible Win32 error code.)

I did.  The consensus I saw was:

five definitions, defined appropriately for each platform (this will msot
likely be different for each platform).

APR_OS_START_ERRNO2 (for platforms that have error codes that overlap with
errno.  ALL platforms would use this, including UNIX)
APR_OS_START_ERROR  (begin APR error codes)
APR_OS_START_STATUS (befin APR status codes)
APR_OS_START_SYSERR (to map errno codes for platforms that don't have
APR_OS_START_USEERR (for APR apps that want to layer their own codes along
with APR.  [Note, I'm not sure how useful this is, personally])

This allows Windows to use whatever values it needs.  It also allows Unix
to use whatever values it needs, and so on.

Now, this may be where things were going, but if so I couldn't tell.  So I
asked for clarification before we went any further.  Usually with a -1,
the person who submitted the patch tries to sway the -1 to a +1 so the
patch can be left in.  I needed and still need clarification to see the
approach that is going to be used for APR error codes.

I may just take today and code what I described above though.


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

View raw message