apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: cvs commit: apr/include apr_errno.h
Date Sun, 13 Oct 2002 15:15:42 GMT
"William A. Rowe, Jr." <wrowe@apache.org> writes:

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

the codes themselves are not distinct...   if you see the value 1, you
donn't know if it is an errno or h_errno or EAI_*

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

personally I don't see the need, since retriable errors surfaced by
resolvers are different than EAGAIN/EWOULDBLOCK "errors" surfaced by
read()/write()/et al...  you don't have the same tools available to
know when to try again...  usually the resolver try-again error is a
hard failure with the user given the decision on what to do next...  I
suspect most people would not find it intuitive to check
APR_STATUS_IS_EAGAIN() 

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

that isn't the case
> 
> 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:

do these functions take parameters?  depending on the platform/call,
error information may or may not be in global (or thread-specific)
variables

> Unix errno, errno, h_errno

where are the EAI codes?

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

I think the gethostbyname mess would be more clearly understandable by
combining the error code gathering with the call itself.  You could
always create some macros so that one of the versions ould be shared
with the Win32 path, but I'm not sure it is worth the penalty of
hiding the gathering of the error code.

Luckily getaddrinfo() was sufficiently described before many vendors
implemented it, and as far as I can tell only one vendor chose to
screw up the error reporting.  Thus, separate Win32 logic isn't going
to make the surrounding code too confusing.

getnameinfo() presents some ugliness since the original description
didn't talk about error reporting and some older implementations did
weird stuff with h_errno.

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Mime
View raw message