A. accept returns a valid address and setsockopt fails afterwards --
This seems like reasonable behaviour on behalf of the kernel. It
gave you back a valid socket but the socket shut down before you
called setsockopt. The standard specifically states that EINVAL can
be caused by:
I suspect that the UNIX '03 conformance changes are the reason why
you're seeing different behaviour on 10.4 vs 10.5.
Thanks for the info. It is a bit frustrating that they have decided
that the same error code is to be returned for two quite different
things, but at least I know now that error code likely to continue to
mean one of those two things.
I filed a bug report on this yesterday, ID 5716640. I have amended it
with a link to that page and a request that the OS X man page be
updated.
B. accept returns a null address -- This smells like a bug to me.
Definitely Radar-worthy IMHO.
Please send me the bug number. Also, if you can include code that
reproduces the problem, that will definitely improve the chances of
it getting fixed (-:
Filed, ID 5718597, with sample code. I have also included it below in
case anyone else is interested, but as far as I am aware it is a
pretty basic example of listening on a TCP socket. If you run it and
scan it with nmap the problem will show up (eg: nmap 127.0.0.1 -p
T:1234). It may need scanned a few times, the RST has to arrive at
just the right time to trip up accept(). Hopefully I can find some
time to do a test and see if doing poll() or select() followed by a
delay followed by accept() will show the problem.