apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: cvs commit: apr/network_io/unix sockaddr.c
Date Tue, 02 Sep 2003 08:22:12 GMT
On Mon, Sep 01, 2003 at 05:41:45PM -0700, Justin Erenkrantz wrote:
> Joe Orton wrote:
> > ...
> >>   +#ifdef SIN6_LEN
> >>   +    sa.sin_len = sizeof(sa);
> >>   +#endif
> > ...
> >
> > Is this bit needed? It causes false negatives on some BSD platforms:
> >
> > configure:20070: checking whether getnameinfo resolves IPv4-mapped IPv6
> > addresses
> > configure:20131: gcc -o conftest -g -O2 -pthread -D_POSIX_THREADS
> > conftest.c -lm -lresolv  1>&5
> > configure: In function `main':
> > configure:20116: structure has no member named `sin_len'
> > configure:20099: warning: return type of `main' is not `int'
> 
> What are our options here?  This exact same code appears in the
> getnameinfo() check (APR_CHECK_WORKING_GETNAMEINFO).  So, how were the
> getnameinfo() checks working on these boxes since they have the same
> #ifdef?  As I read the checks, we shouldn't even be detecting
> getnameinfo() as working because the compilation should fail.  Those boxes
> should be non-IPv6 capable, and the macro to validate getnameinfo()'s
> mapping of IPv4 addresses shouldn't be executed.

Ah, the new macro uses a sockaddr_in6 though not a sockaddr_in like the
old one, so it's not surprising it doesn't have any sin_* members... I'd
still like to know why sin_len is used at all in the original macro, but
I've checked in the obvious fix.

> (I just copied the getnameinfo() macro.)
> 
> > (the sockaddr.c build also breaks on a subset of these platforms because
> > uint32_t is not defined but I guess that will go away once the autoconf
> > code is fixed)
> 
> Yes, it probably should be apr_uint32_t.  -- justin

funny thing is I wouldn't have noticed the false positives if it had
been an apr_uint32_t :)

joe

Mime
View raw message