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

Reply via email to