You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by wr...@apache.org on 2002/10/13 06:08:35 UTC
cvs commit: apr/include apr_errno.h
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?
Revision Changes Path
1.96 +25 -4 apr/include/apr_errno.h
Index: apr_errno.h
===================================================================
RCS file: /home/cvs/apr/include/apr_errno.h,v
retrieving revision 1.95
retrieving revision 1.96
diff -u -r1.95 -r1.96
--- apr_errno.h 15 Aug 2002 17:56:04 -0000 1.95
+++ apr_errno.h 13 Oct 2002 04:08:34 -0000 1.96
@@ -770,6 +770,21 @@
#define INCL_DOSERRORS
#define INCL_DOS
+
+/* Leave these undefined.
+ * OS2 doesn't rely on the errno concept.
+ * The API calls always return a result codes which
+ * should be filtered through APR_FROM_OS_ERROR().
+ *
+ * #define apr_get_os_error() (APR_FROM_OS_ERROR(GetLastError()))
+ * #define apr_set_os_error(e) (SetLastError(APR_TO_OS_ERROR(e)))
+ */
+
+/* A special case, only socket calls require this:
+ */
+define apr_get_netos_error() (APR_FROM_OS_ERROR(h_errno))
+define apr_set_netos_error(e) (h_errno = APR_TO_OS_ERROR(e)))
+
/* And this needs to be greped away for good:
*/
#define APR_OS2_STATUS(e) (APR_FROM_OS_ERROR(e))
@@ -924,6 +939,7 @@
/* A special case, only socket calls require this:
*/
#define apr_get_netos_error() (APR_FROM_OS_ERROR(WSAGetLastError()))
+#define apr_set_netos_error(e) (WSASetLastError(APR_TO_OS_ERROR(e)))
#define APR_STATUS_IS_SUCCESS(s) ((s) == APR_SUCCESS \
|| (s) == APR_OS_START_SYSERR + ERROR_SUCCESS)
@@ -1026,12 +1042,12 @@
#define APR_FROM_OS_ERROR(e) (e)
#define APR_TO_OS_ERROR(e) (e)
-#define APR_TO_NETOS_ERROR(e) (e-APR_OS_START_SYSERR)
#define apr_get_os_error() (errno)
#define apr_set_os_error(e) (errno = (e))
#define apr_get_netos_error() (WSAGetLastError()+APR_OS_START_SYSERR)
+#define apr_set_netos_error(e) (WSASetLastError((e)-APR_OS_START_SYSERR))
#define APR_STATUS_IS_SUCCESS(s) ((s) == APR_SUCCESS)
@@ -1084,15 +1100,20 @@
*/
#define APR_FROM_OS_ERROR(e) (e)
#define APR_TO_OS_ERROR(e) (e)
+/* Platform specific, should be deprecated */
+#define APR_TO_NETOS_ERROR(e) (e-APR_OS_START_SYSERR)
#define apr_get_os_error() (errno)
#define apr_set_os_error(e) (errno = (e))
/* A special case, only socket calls require this:
- * [Note: platforms using h_errno should replace this macro,
- * although watch out for thread saftey issues with h_errno.]
*/
-#define apr_get_netos_error() (errno)
+#define apr_get_netos_error() (h_errno)
+#ifdef HAVE_SET_H_ERRNO
+#define apr_set_netos_error(e) set_h_errno(e)
+#else
+#define apr_set_netos_error(e) (h_errno = (e))
+#endif
/** no error */
#define APR_STATUS_IS_SUCCESS(s) ((s) == APR_SUCCESS)
Re: cvs commit: apr/include apr_errno.h
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jeff...
I finally see that h_errno values don't map to the errno domain,
and that only
[HOST_NOT_FOUND]
[NO_DATA]
[NO_RECOVERY]
[TRY_AGAIN]
are supported. Yes you are right on h_errno... that should be totally
internal to the use of fns.
However, I'm increasingly concerned that we need appropriate result
APR_STATUS_IS_Efoo() tests (to the caller of APR) for the results
of the network host db functions whenever we use endhostent,
gethostbyaddr, gethostbyname, gethostent, and sethostent. That
probably means mapping them into typical APR_Efoo() errors, since
the caller isn't allowed to look at errno (it's not a defined result of
any apr_ calls.)
I'm cleaning up the changes now and will come back with the right
code for h_errno stuff.
Bill
At 10:15 AM 10/13/2002, Jeff Trawick wrote:
>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_*
Re: cvs commit: apr/include apr_errno.h
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jeff...
I finally see that h_errno values don't map to the errno domain,
and that only
[HOST_NOT_FOUND]
[NO_DATA]
[NO_RECOVERY]
[TRY_AGAIN]
are supported. Yes you are right on h_errno... that should be totally
internal to the use of fns.
However, I'm increasingly concerned that we need appropriate result
APR_STATUS_IS_Efoo() tests (to the caller of APR) for the results
of the network host db functions whenever we use endhostent,
gethostbyaddr, gethostbyname, gethostent, and sethostent. That
probably means mapping them into typical APR_Efoo() errors, since
the caller isn't allowed to look at errno (it's not a defined result of
any apr_ calls.)
I'm cleaning up the changes now and will come back with the right
code for h_errno stuff.
Bill
At 10:15 AM 10/13/2002, Jeff Trawick wrote:
>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_*
Re: cvs commit: apr/include apr_errno.h
Posted by Jeff Trawick <tr...@attglobal.net>.
"William A. Rowe, Jr." <wr...@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...
Re: cvs commit: apr/include apr_errno.h
Posted by Jeff Trawick <tr...@attglobal.net>.
"William A. Rowe, Jr." <wr...@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...
Re: cvs commit: apr/include apr_errno.h
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Sun, 13 Oct 2002 09:22:09 -0500, William A. Rowe, Jr. wrote:
>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
OS/2 actually has a sock_errno() function that works much like
WSAGetLastError(). The values it returns are biased so as to not conflict
with system errors, going from 10000->10066. The h_errno is correct though
& has values -1,1->4 which DOES conflict with system error codes.
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: cvs commit: apr/include apr_errno.h
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
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
Re: cvs commit: apr/include apr_errno.h
Posted by Jeff Trawick <tr...@attglobal.net>.
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.
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.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: cvs commit: apr/include apr_errno.h
Posted by Jeff Trawick <tr...@attglobal.net>.
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.
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.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...