httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: cvs commit: apache-2.0/src/lib/apr/include apr_errno.h
Date Wed, 05 Apr 2000 15:36:14 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
> them?  

If I interpret your disagreement with my APRDesign properly, you
disagreed with the idea that APR should translate OS-specific error
codes into portable APR error codes.  

Nothing in my changes made APR translate OS-specific error codes into
portable APR error codes.  Instead, it made it possible to return
OS-specific error codes without having them confused with something else.

> 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.
> But what you are doing, AFAICT, is requiring that each platform returns
> the same value when there is an error.  

Show me the line of code in my change that does that.  There is no
such line of code in the change.

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

Where in the heck did that come from?  If this was the consensus,
surely it should have been mentioned before at least once?  I'm having
trouble following your logic.  Maybe you are using that name instead
of APR_OS_START_OSERR.  I don't care what the name is so much, but if
you want to change the name, say so.  

> 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
> them)
> 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 is all old crap that was there before and which I didn't change.
Why is this an issue now?

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

The important part of the change was creating a macro to use to store
an OS error in ap_status_t.  Who cares what the offsets are?  That is
a trivial tweak at any point in the future.  What is needed
immediately is a macro.

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

This is just more of what has been going on for the last week.  We are
going around and around talking at each other but not really
communicating.  At least now there are only two people involved
instead of four, so that is some improvement.  And there will be zero
or one left (your choice) after this post.

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

I look forward to your resolution of this issue.  It doesn't have to
be pretty.  It doesn't even have to compile.  But it needs to define a
way to return an OS-specific error code in a way that we don't have to
change 500 lines of code when somebody comes up with a better encoding
mechanism later.

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

View raw message