Hi folks...

I'll start with a very brief introduction -- I just joined this mailing list, so that I could report a Hurd bug I found last night.  I never used the Hurd before yesterday, but I would be interested in working with it, if I can just find the time...

Anyway, I was on #hug on IRC last night, talking to "bddebian", who was having trouble getting "orbit2" (GNOME's CORBA broker) to run on the Hurd.  I offered to help, so he gave me an account on his machine and I traced the problem, which turned out to be that getsockname() was returning a null pathname instead of the correct pathname of the Unix-domain socket.  Since orbit2 expects this call to work, it broke the software.  After I found the problem, I stripped down the code to a 36-line test case (attached) which exhibits the bug.  Under Linux, getsockname() returns the same sockaddr_un structure that was sent to bind(), while the Hurd is returning a null path instead.

This morning, I took a quick glance at the Hurd sources, and noticed the following comment on S_socket_whatis_address() in hurd/pflocal/pf.c:

/* Implement socket_whatis_address as described in <hurd/socket.defs>.
   Since we cannot tell what our adress is, return an empty string as
   the file name.  This is primarily for the implementation of accept
   and recvfrom.  The functions getsockname and getpeername remain
   unsupported for the local namespace.  */

So it appears that no attempt was ever made to implement getsockname() or getpeername() for Unix-domain sockets.

Since this bug (unsupported feature) may break other applications
besides orbit2, perhaps someone would like to take a stab at  filling in the gap?

Deven