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 Showstoppers to apr release(?)
Date Mon, 15 Oct 2007 05:38:10 GMT
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.

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

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

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

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

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


Given how many issues we've had to correct in the past, this is overall not very
disappointing.  I'll be submitting proposed proc.c flavors to trunk/ for OS2,
Netware and BEOS once I incorporate the final round of unix/proc changes to them.

Mime
View raw message