apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@apache.org>
Subject Re: cvs commit: apr/include apr_errno.h
Date Sun, 13 Oct 2002 14:22:09 GMT
At 07:22 AM 10/13/2002, Jeff Trawick wrote:
>wrowe@apache.org writes:
>
>> wrowe       2002/10/12 21:08:34
>> 
>>   Modified:    include  apr_errno.h
>>   Log:
>>     Consistify apr_get_netos_error() and apr_set_netos_error().
>>   
>>     Only remaining question... are h_errno values in the errno domain,
>>     or are they in their very own conflicting range?
>
>here are three sets of "net" error codes which can have conflicting
>ranges:
>
>1) errno, as set by kernel calls and sometimes getaddrinfo()
>2) h_errno, as set by some resolver calls
>3) EAI_* retcodes from getaddrinfo() (but one of the retcodes says
>   "look at errno"
>
>   on at least one very significant platform, EAI_* values are
>   negative :(
>
>The very notion of xxx_netos_error() can be confusing to some of us
>who have to keep those three sets in mind, especially since different
>"net" routines return/set any of three distinct types of error codes.

Let's go through them one at a time...

>1) errno, as set by kernel calls and sometimes getaddrinfo()

This is clean on Unix (via errno) because we don't remap them at all.
They remain in their 0-n range.  On Win32 and other oddballs, we also
use that 0-n range for EFOO codes on the C compatibility layer.

On WinSock platforms, errno is not used by socket/send/recv et al,
since those map to Net OS errors.  On Unix, I understand that socket,
send, recv are truly kernel errors (errno).

Let's suppose we have a flag APR_ALL_SOCK_ERR (or some better
name), which enforces that *all* socket operations on this oddball 
or WinSock platform map instead into...


>2) h_errno, as set by some resolver calls

So on most platforms the netdb resolver uses h_errno rather than errno
to stash these return values.   BUT, are the codes distinct from errno,
or do they map properly to the same 0-n values as errno?

On WinSock based platforms, of course, WSA_ codes don't map into
the errno space, so they must be floated up to the OS_ERR space.
But we provide the appropriate tests in APR_STATUS_IS_E{sockerr}
to deal with those issues.


>3) EAI_* retcodes from getaddrinfo() (but one of the retcodes says
>   "look at errno"

These clearly don't fall into either the apr_{get/set}_os_error or 
apr_{get/set}_netos_error groups.  However, if we test the condition
APR_STATUS_IS_EAGAIN(EAI_AGAIN) ... shouldn't it return True?

On Win32, EAI_ results are discouraged and WSAGetLastError()
will return the corresponding WSA_ error.  They are primarily discouraged
because gai_strerror is documented as *not thread safe* on Win32.


>I know you were "concerned" about the lack of use of XXX_netos_error()
>in some of the common code in the past, but from my perspective it is
>just an impediment to me being able to verify that the correct range
>(for the 3 types of network errors) is actually being used.

It's not an abstract concern... as win32 IPV6 needs the getnameinfo()
and getsockaddr() functions in sa_common, this became a real issue.

If errno and h_errno numbers map into the same EFOO domains, there
is no purpose in assigning different ranges, correct?  EAI_ clearly needs 
it's own range, and I did not attempt to abstract those.  EAI_ errors only 
occur as the return value of the getsockaddr() call, which makes those
puppies pretty simple.

I recognize that for convience, it's easier to just stub in macros and
mappings throughout the source.  And in some cases that's entirely
appropriate (e.g. negative EAI's.).  Generally, however, this exposes
our code to platform specific anomalies that are better sorted out
up front, by doing the 'right thing' in apr_errno.h.

I'm going to try to grid these up in a document to clarify where these 
can all originate from, what they result in, and come up with a plan
to distinguishing netdb errors from general socket API errors.

Would the separation get_os_error, get_netos_error, get_netdb_error
make sense for resolving into:

Unix errno, errno, h_errno
Netware errno, WSAGetLastError, WSAGetLastError
Win32 GetLastError, WSAGetLastError, WSAGetLastError
OS2 {not applicable}, errno, h_errno

I'm hoping those three groups would sit well.  Of course some code
will be needed if an oddball error could be returned in either netdb or
the netos error result.

Bill


Mime
View raw message