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.
