Error values in APR.

[Ryan Bloom <rb...@raleigh.ibm.com>]

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.	

Re: Error values in APR.

[Rodent of Unusual Size <Ke...@Golux.Com>]

I think this covers apr_status_t with values named APR_foo, yes?
For Unix (or platforms which define E* names), I see

#define APR_EPERM  EPERM
#define APR_ENOENT ENOENT
	:

and on Windows or other don't-have-E*-names-defined platforms,

#define APR_EPERM  1
#define APR_ENOENT 2
	:

or perhaps an enum.  The names will be familiar to Unix coders,
and won't break if they use 'EPERM' instead of 'APR_EPERM' (though
I'm not sure we should encourage or even mention that), and it's
a transparent abstraction of the error conditions.

Just off the top of my head..
-- 
#ken    P-)}

Ken Coar                    <http://Web.Golux.Com/coar/>
Apache Software Foundation  <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>

Re: Error values in APR.

[Dean Gaudet <dg...@arctic.org>]

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