Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Wed, 5 Apr 2000 00:08:22 -0400
Message-Id: <200004050408.AAA17748@k5.localdomain>
From: Jeff Trawick <trawickj@bellsouth.net>
To: new-httpd@apache.org
In-reply-to: <Pine.LNX.4.10.10004042321470.28840-100000@shell.ntrnet.net>
	(rbb@apache.org)
Subject: Re: cvs commit: apache-2.0/src/lib/apr/include apr_errno.h
Reply-to: trawickj@bellsouth.net
References: <Pine.LNX.4.10.10004042321470.28840-100000@shell.ntrnet.net>

> -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.

> 
> We have talked about this for a week, and this is not the implementation I
> thought we decided on.

Perhaps you can clarify who decided what and which part of this change
violates that.  This patch, which was posted almost exactly like this
a couple of days ago with no comment from you, is pretty much a
lowest-common-denominator (i.e., elements that were closest to
concensus) of the many issues which have been discussed.  I hardly
think that the current use of the same value of APR_OS_START_OSERR for
all platforms, which was not in the last patch I posted, is enough to
justify claiming a lack of fair warning.  Life goes on, and somebody
has to make the code move forward too.  These were baby steps from
what had been posted earlier. 

> First of all, this still has a common value for all five of the status
> defines.  The final number, APR_OS_START_OSERR looks like an arbitrary
> number to me.

There are certainly a great number of values which meet the
requirements.  Within that set of values it is certainly fair to say
that it was an arbitrary selection.  

My firm requirement was:

. works for all OS-specific error codes which can be expected to be
returned by OS-specific calls that APR makes *right now*, to the best
of my knowledge

My soft requirements were:

. uses a nice round number for the offset so that it is easy to tell
  in a debugger what OS-specific value was received

Other requirements I heard voiced were:

. use the same value for offset on all platforms

. 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.

> Also, why are we wrappering all of these defines with ifndef's?  The whole
> file is wrappered protected, so why are we protecting those definitions as
> well?

There was quite a bit of that already.  I assumed it was to allow for
the possiblity of additional tailoring at compile time.  I continued
that with the new offset and the new macros.  I really don't care
either way and did so only because that seemed to be the precedent.
I'm happy to yank it out.

> 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.

>                                                                        To
> 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.)

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