apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Showstoppers to apr release(?)
Date Tue, 30 Oct 2007 05:10:17 GMT
William A. Rowe, Jr. wrote:
> Here's my list of open issues which should probably be determined before
> we roll out 1.2.x, I was hoping we were further along than this on Unix
> in particular;
> 
> * HP/UX 11.11i testatomic.c:288  Failed creating threads???  Investigating,
>   it happens to be the only testatomic failure (1/17).  Enabling the
>   concurrency, which it appears we can, has no effect.

No clue yet - if anyone has a box, help is appreciated.

> * Solaris 10, testpoll.c:314 we are failing with only APR_POLLOUT when we
>   had expected both APR_POLLIN and APR_POLLOUT to be signaled.  Ideas?

Anyone care enough about solaris to investigate?  Happy to provide more hints.

> * HP/UX 11.11i fails in a fun way at testsockets.c:85, 100 and 127, we see
>   error 221 EPROTONOSUPPORT instead of 225 EAFNOSUPPORT.  Very odd :)
>   Do we add this to APR_STATUS_IS_EAFNOSUPPORT or otherwise combine them?

Feedback please?  Can EPROTONOSUPPORT be added to APR_STATUS_IS_EAFNOSUPPORT?

> * Solaris 10, testsockets.c:146 fails in an interesting way when we haven't
>   bound an IPv6 adapter (including ::1), it successfully binds and then
>   fails at 146 with ENOKEY (126)???  Clues?

Again, anyone care enough about solaris to look at ENOKEY?

> * Sol, Linux, HP, Win32, testsockets:146 saw port 4242 when we expected recvfrom
>   to fill in port 7771 for IPv6; more fun on AIX, I'm seeing this 2x!  I'm
>   very confused if we promise this in our API contract or should defer fixing
>   this until APR 1.3.0.  Thoughts?

Thanks to Joe's hints, this is cleared out.

> * Win32 built IPv6 without an IPv6 protocol driver, it definitely cannot parse
>   a mixed IPv6 dotted IP, and returns SUCCESS with a null sa.  This triggers
>   failures (no longer faults) at testipsub:139 and testsock:227.  Should we
>   patch to present this as some sensible error return?  Is the client expected
>   to look out for a NULL sa?  Thoughts please, see my earlier thread on the
>   topic, I've only learned that it's ::n.n.n.n syntaxes that die without some
>   help from the protocol layer.

Just pinged on this already.

Maybe presume EAFNOSUPPORT if we see "success" with not a single address?

Bill

Mime
View raw message