apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apr/network_io/unix sa_common.c
Date Thu, 14 Dec 2000 12:07:11 GMT
While a bit more complicated, it should be completely possible to assign
non-intersecting ranges at configure time, based on discovery of the actual
ranges used on the box.

e.g. have a config test to see whether EAI_* is positive or negative, and
adjust the APR error space accordingly.

The other alternative, of course, is to start using a more complicated error
system :-)

Cheers,
-g

On Thu, Dec 14, 2000 at 05:58:51AM -0500, Jeff Trawick wrote:
> "Brian Havard" <brianh@kheldar.apana.org.au> writes:
> 
> > On 13 Dec 2000 22:30:22 -0000, trawick@locus.apache.org wrote:
> > 
> > >  OS/2 and Win32 logic for reporting getaddrinfo() failures is from existing
> 
>            should have been gethostbyaddr() instead of getaddrinfo()
> 
> > >  code.  The OS/2 code doesn't look right to me (need to add APR_OS_START_xyz?)
> > >  I'm not sure what is needed for pre-BONE BeOS.
> > 
> > Actually, h_error on OS/2 needs to be sorted out somehow as there's
> > currently no place for it in apr_error_t space, the only existing use of it
> > on OS/2 is wrong. I think we need a standard place for it so OS/2 & Unix
> > code can share code without these #ifdefs, maybe somewhere in the
> > APR_OS_START_ERROR->APR_OS_START_STATUS range. There's space for 500 codes
> > there of which 20 are used.
> 
> Another horror to deal with is the set of errors from getaddrinfo().
> Not only do they need to be distinguished between errno and h_errno
> and APR-specific values, but with glibc the values are negative
> (but positive on the other systems I have access to):
> 
> /* Error values for `getaddrinfo' function.  */
> # define EAI_BADFLAGS   -1      /* Invalid value for `ai_flags' field.  */
> # define EAI_NONAME     -2      /* NAME or SERVICE is unknown.  */
> # define EAI_AGAIN      -3      /* Temporary failure in name resolution.  */
> # define EAI_FAIL       -4      /* Non-recoverable failure in name res.  */
> # define EAI_NODATA     -5      /* No address associated with NAME.  */
> # define EAI_FAMILY     -6      /* `ai_family' not supported.  */
> # define EAI_SOCKTYPE   -7      /* `ai_socktype' not supported.  */
> # define EAI_SERVICE    -8      /* SERVICE not supported for `ai_socktype'.  */
> # define EAI_ADDRFAMILY -9      /* Address family for NAME not supported.  */
> # define EAI_MEMORY     -10     /* Memory allocation failure.  */
> # define EAI_SYSTEM     -11     /* System error returned in `errno'.  */
> 
> -----cut to the chase-----
> 
> I think we should just explicitly define a bunch of APR resolver error
> codes and map from h_errno and from getaddrinfo() return codes to
> those APR codes directly.  Other ways to handle it use less explicit
> games which muddy the error code space for all platforms.
> 
> We would need four new APR error codes: APR_ENONAME, APR_ENORECOVERY,
> APR_ENODATA, APR_EAFNOSUPPORT.
> 
> h_errno 
> 
>   HOST_NOT_FOUND      -> APR_ENONAME
>   TRY_AGAIN           -> APR_EAGAIN?
>   NO_RECOVERY         -> APR_ENORECOVERY
>   NO_DATA, NO_ADDRESS -> APR_ENODATA
> 
> getaddrinfo()
> 
>   EAI_BADFLAGS        -> APR_EINVAL?
>   EAI_NONAME          -> APR_ENORESNAME
>   EAI_AGAIN           -> APR_EAGAIN?
>   EAI_FAIL            -> APR_ENORECOVERY
>   EAI_NODATA          -> APR_ENODATA
>   EAI_FAMILY          -> APR_EAFNOSUPPORT
>   EAI_SOCKTYPE        -> APR_EINVAL    (shouldn't be possible for us)
>   EAI_ADDRFAMILY      -> APR_EAFNOSUPPORT
>   EAI_MEMORY          -> APR_ENOMEM
>   EAI_SYSTEM          -> use errno
> 
> The Win32 support, which doesn't use h_errno, can continue to use its
> current code.
> 
> Any thoughts?  I'd like to wrap up the gaping getaddrinfo() hole
> before too long. 
> 
> ------my original thoughts...-----
> 
> Back to your problem...
> 
> As I think you suggest:
> 
> #define APR_OS_START_RES_ERROR     APR_OS_START_ERROR + 200
> 
> Any system where h_errno is used will return (h_errno +
> APR_OS_START_RES_ERROR) and magic will happen.
> 
> Back to my problem with this second set of res errors on Unix...
> 
> #define APR_OS_START_RES_ERROR_MAX   APR_OS_START_RES_ERROR + 50
> #define APR_OS_START_RES_ERROR_2     APR_OS_START_RES_ERROR + 100
> 
> The ugly APR_OS_START_RES_ERROR_MAX is because of the ugly glibc use
> of negative values for the EAI_ codes.  Something higher than
> APR_OS_START_RES_ERROR_MAX but less than the next range after
> APR_OS_START_RES_ERROR_2 is presumed to be one of these second set of
> resolver error codes.
> 
> Returning an EAI_ code in sa_common.c:
> 
>   if ((error = getaddrinfo()) != 0) {
>       return APR_OS_START_RES_ERROR_2 + error;
>   }
> 
> Finding the string for an EAI_ code in errorcodes.c:
> 
>     if (statcode < APR_OS_START_ERROR) {
>         return stuffbuffer(buf, bufsize, strerror(statcode));
>     }
>     else if (statcode < APR_OS_START_RES_ERROR) {
>         return stuffbuffer(buf, bufsize, apr_error_string(statcode));
>     }
>     else if (statcode < APR_OS_START_RES_ERROR_MAX) {
> #ifdef HAVE_H_ERRNO
>         /* it is an h_errno value */
> #else
>         "APR does not understand this error code"
> #endif
>     }
>     else if (statcode < APR_OS_START_STATUS) {
> #ifdef HAVE_GAI_STRERROR
>         /* it is a getaddrinfo() error */
> #else
>         "APR does not understand this error code"
> #endif
>     }
>     else if (statcode < APR_OS_START_USEERR) {
>         return stuffbuffer(buf, bufsize, apr_error_string(statcode));
>     }
>     else if (statcode < APR_OS_START_SYSERR) {
>         return stuffbuffer(buf, bufsize, "APR does not understand this error code");
>     }
>     else {
>         return apr_os_strerror(buf, bufsize, statcode - APR_OS_START_SYSERR);
>     } 
> 
> -- 
> Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
>        http://www.geocities.com/SiliconValley/Park/9289/
>              Born in Roswell... married an alien...

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message