You will probably get the same behavior out of this anyway, but (A) it would be good to make sure, and (B) the corrected code may be of academic interest to you.

[Butte:Users/cherf/tmp] cherf% bindit /tmp/some.socket
[Butte:Users/cherf/tmp] cherf% uname -a
Darwin Butte.local 10.6.0 Darwin Kernel Version 10.6.0: Wed Nov 10 18:13:17 PST 2010; root:xnu-1504.9.26~3/RELEASE_I386 i386

Here it is again on the server:

[alphonse:~/tmp] cherf% bindit some.socket
bind: Invalid argument
[alphonse:~/tmp] cherf% bindit /tmp/some.socket
bind: Address already in use
[alphonse:~/tmp] cherf% rm /tmp/some.socket
[alphonse:~/tmp] cherf% bindit /tmp/some.socket
[alphonse:~/tmp] cherf% uname -a
Darwin alphonse 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov  3 10:37:10 PST 2009; root:xnu-1486.2.11~1/RELEASE_I386 i386

You may notice the error s different between 10.6.6 (development machine "Butte") and 10.6.2 (server "Alphonse")

Yep.

I believe this implies bind will not accept a relative pathname for a unix family socket under 10.6

I think you mean "under 10.6.2"; this definitely works on other versions.  That is a reasonable interpretation, although I don't have any 10.6.2 machines to test on at the moment.  Neither should you, really; update both those machines to 10.6.7. :)

Please let me know if that's also your interpretation. If you'd like a complete copy of the modified test let me know. All I did really was malloc the socket address so I could stuff a variable length pathname into it.

You shouldn't be needing to malloc() sockaddrs; they all have a fixed length.  You're right that my previous example was a little bogus though, the current one should illustrate it better.

Regards and thanks again,

No problem.  This sounded like a really juicy problem, but I guess we've come to the rather pedestrian conclusion that you should just update your server :).

One final note: in your previous message, you said:

The previous pathname length was 87 characters (plus 12 for "/some.socket" = 99) which doesn't seem too long for a POSIX name.

That is under the maximum, but only just.  This standard reference may be of interest to you:

<http://pubs.opengroup.org/onlinepubs/009604499/basedefs/sys/un.h.html>

The size of sun_path has intentionally been left undefined. This is because different implementations use different sizes. For example, 4.3 BSD uses a size of 108, and 4.4 BSD uses a size of 104. Since most implementations originate from BSD versions, the size is typically in the range 92 to 108.

Applications should not assume a particular length for sun_path or assume that it can hold {_POSIX_PATH_MAX} characters (255).

Scott.