httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: Error values in APR.
Date Thu, 20 May 1999 20:50:59 GMT
This is almost what I suggested in a message entitled "I see the light" 
about two months ago... 

btw -- when I suggested "errno" a long time ago, I wasn't suggesting using
errno itself, just using the concept.  A thread local error value. 

Dean

On Thu, 20 May 1999, Ryan Bloom wrote:

> 
> Look out, I'm being creative again.  :)
> 
> Months and months ago, back when we started designing this apr creature,
> we talked about having every function return a status code, and the
> decision was to use errno.
> 
> We have hit a brick wall.  Win32 API calls don't set errno, and I can't
> set errno, because on some systems, it is either a macro or function (OS/2
> is a good case).
> 
> So, unless somebody has a REALLY good reason that this is a bad idea, here
> is my current thinking (to be refined as it is implemented).
> 
> ap_status_t stops returning success and failure.  Instead all functions
> return an ap_status_t which is defined this way:
> 
> 0 SUCCESS.
> 
> E* (this is a valid errno value.  Obviously, if a function returned an
> error condition, we just return the errno value, and life moves on.)  On
> non-posix platforms, i.e. windows, we will approximate the errno value as 
> best as we can.  For example, if we go to open a file we don't have access
> to, GetLastError() will return ERROR_ACCESS_DENIED, and we can just return
> EACCES.  This will mean that on Windows systems, we will have to define a
> lot of return values, because the list of E* that they support is minimal
> to say the least.
> 
> >4000 these are APR errno values that are defined as needed.
> 
> This has the advantage of being portable (defining values for errno is a
> simple matter of #define on systems that don't have them), and being easy
> to understand.  It is also VERY similar to using errno on platforms that
> support it.
> 
> If there are no objections, I will begin to change the current code to use
> this system on Monday.
> 
> Ryan
> 
> _______________________________________________________________________
> Ryan Bloom		rbb@raleigh.ibm.com
> 4205 S Miami Blvd	
> RTP, NC 27709		It's a beautiful sight to see good dancers 
> 			doing simple steps.  It's a painful sight to
> 			see beginners doing complicated patterns.	
> 
> 
> 
> 
> 


Mime
View raw message