Can you show us a program that fails?

Sure, here it is. Thank you.

Client code:

package main

import "net"

func main() {
        _, err := net.Dial("unix", "@/Foo/bar1234")
        if err != nil {
                panic(err)
        }
}

Failing server code:

#include <fcntl.h>
#include <string.h>
#include <sys/socket.h>
#include <sys/un.h>

int main() {
   int fd = socket(AF_UNIX, SOCK_STREAM, 0);
   fcntl(fd, F_SETFD, FD_CLOEXEC);
   struct sockaddr_un sun;
   memset(&sun, 0, sizeof(sun));
   sun.sun_family = AF_UNIX;
   strncpy(sun.sun_path, "@/Foo/bar1234", sizeof(sun.sun_path));
   sun.sun_path[0] = '\0';
   bind(fd, (sockaddr *) &sun, sizeof(sun));
   listen(fd, 255);
   while (true) {}
}

Working server code:

#include <fcntl.h>
#include <string.h>
#include <sys/socket.h>
#include <sys/un.h>

int main() {
   int fd = socket(AF_UNIX, SOCK_STREAM, 0);
   fcntl(fd, F_SETFD, FD_CLOEXEC);
   struct sockaddr_un sun;
   memset(&sun, 0, sizeof(sun));
   sun.sun_family = AF_UNIX;
   strncpy(sun.sun_path, "@/Foo/bar1234", sizeof(sun.sun_path));
   int sun_len = strlen(sun.sun_path);
   sun.sun_path[0] = '\0';
   bind(fd, (sockaddr *) &sun, sun_len + sizeof(sun.sun_family));
   listen(fd, 255);
   while (true) {}
}

The server was compiled with gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4).

Output:

$ gcc server_ok.cpp && ./a.out &
[1] 16593
$ go run client.go 
$ killall a.out
/bin/bash: line 15: 16603 Terminated              ./a.out
[1]+  Exit 143                gcc server_ok.cpp && ./a.out
$ gcc server_fail.cpp && ./a.out &                                                                                                                                                                                    
[1] 17557
$ go run client.go                                                                                                                                                                                                    
panic: dial unix @/Foo/bar1234: connection refused

goroutine 1 [running]:
main.main()
        /home/gvalente/id/src/tacc/client.go:8 +0x6c

goroutine 2 [runnable]:
runtime.forcegchelper()
        /usr/lib/go/src/runtime/proc.go:90
runtime.goexit()
        /usr/lib/go/src/runtime/asm_386.s:2287 +0x1

goroutine 3 [runnable]:
runtime.bgsweep()
        /usr/lib/go/src/runtime/mgc0.go:82
runtime.goexit()
        /usr/lib/go/src/runtime/asm_386.s:2287 +0x1

goroutine 4 [runnable]:
runtime.runfinq()
        /usr/lib/go/src/runtime/malloc.go:712
runtime.goexit()
        /usr/lib/go/src/runtime/asm_386.s:2287 +0x1
exit status 2

From bind(2) manual:

The rules used in name binding vary between address families. Consult the manual entries in Section 7 for detailed information. For AF_INET see ip(7), for AF_INET6 see ipv6(7), for AF_UNIX see unix(7), for AF_APPLETALK see ddp(7), for AF_PACKET see packet(7), for AF_X25 see x25(7) and for AF_NETLINK see netlink(7).

From unix(7) about AF_UNIX family sockets:

pathname: a UNIX domain socket can be bound to a null-terminated file system pathname using bind(2). When the address of the socket is returned by getsockname(2), getpeername(2), and accept(2), its length is offsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1, and sun_path contains the null-terminated pathname.

From sys/un.h

# define SUN_LEN(ptr) ((size_t) (((struct sockaddr_un *) 0)->sun_path)        \
                     + strlen ((ptr)->sun_path))

IMHO: The patched C++ code (bind(fd, (sockaddr *) &sun, sun_len + sizeof(sun.sun_family))) is the correct code, so this is not an actual bug.

FWIW the EXAMPLES section of bind(2) has this code in it:

           if (bind(sfd, (struct sockaddr *) &my_addr,
                   sizeof(struct sockaddr_un)) == -1)
               handle_error("bind");

The example in the bind(2) man page is not for an abstract socket address. I don't know that we should consider it as more relevant than the unix(7) man page. For an abstract socket address the unix(7) man page says that addrlen describes the socket address. Evidently the client and server must agree on the how the length is set, but it's not clear that the Go approach is incorrect, given that it seems to match what the unix(7) man page says.

That's right, kind of confusing but I guess Go is doing the right thing. Thank you for looking into this.