httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Havard" <bri...@kheldar.apana.org.au>
Subject Re: APR errno handling finished.
Date Thu, 06 Apr 2000 00:27:41 GMT
On Wed, 5 Apr 2000 19:47:37 -0400 (EDT), rbb@apache.org wrote:

>> >I am posting a patch here that implements this, as well as an extra file
>> >that will need to be flushed out to actually finish the work, but this
>> >version of the file does get things started.
>> >
>> >The docs are all in APRDesign in this patch.  This is the design I thought
>> >we had agreed upon in the last few weeks.  It is basically Ben Laurie's
>> >idea, as I understand it, written out as code and flushed out a tiny
>> >little bit.
>> >
>> >If nobody objects, I'll commit this tomorrow evening West Coast Time.  :-)
>> 
>> I object!
>> Doing it this way prevents using default unix implementaions on non-unix
>> platforms, leading to total code duplication. It's also totally different
>> from my proposal which you said you liked.
>
>I didn't understand your proposal.  This is what I thought you were
>getting at.  And, if you wrap your head around this, it is what you were
>proposing.  Make one small change.  On OS/2, the primary error values are
>errno values, and the supplemental values are OS/2 values.
>
>If you think of it that way, this is exactly what you proposed.

They way I proposed, errno is the 'primary' code on all platforms, which
makes the whole concept unnecessary. OS/2 & Win32 are almost identical in
their error codes. How can it make sense for them to be handled
differetnly? Why should the use of errno on Windows be banned?



>primary values are reported as is.  Any platform which uses Unix code
>would have to have a primary error value that uses errno values.
>
>supplemental values get the offset added.  By definition if the OS/2 error
>values aren't primary error values, they are supplemental.

That would be confusing. The vast majority of OS/2 APR code returns OS/2
error codes.


I still think my scheme is much simpler, cleaner, and allows everything we
want. With the only problem of possible code overflow, it should be easy to
prove it a non-issue by checking the code range of all platforms. Win32
looks clear, OS/2 never goes over 2^16. What about BeOS?


Could everyone look over what I wrote in 
"Re: ap_status_t for non-unix platforms"
and comment on it? I even drew a diagram!

-- 
 ______________________________________________________________________________
 |  Brian Havard                 |  "He is not the messiah!                   |
 |  brianh@kheldar.apana.org.au  |  He's a very naughty boy!" - Life of Brian |
 ------------------------------------------------------------------------------


Mime
View raw message