Comment 1:

Labels changed: added repo-main, release-go1.4.

Comment 2:

The difference between the two tests is that ListenUDP both creates the socket and calls
Bind to listen to the given address (":1025"). The TestSyscalls version is not doing the
Bind. They are not comparable.
If you need a special socket option before bind, the easiest way to do that is to create
the socket yourself, following the code in TestSyscall (but adding a Bind), and then
call net.FileConn(os.NewFile(fd)) to get a net.Conn for it.
Note that calling the File method on a net.Conn puts it in blocking mode, which will
limit your scalability. So creating the socket yourself is probably the best option
anyway.

Status changed to Unfortunate.

Comment 3 by omrib@everything.me:

What I was trying to show is that the bug is caused because we're calling bind() before
the setsockopt().
You can't use Setsockopt() on sockets created with the standard library on Mac (because
the socket object is returned after a call to bind()).
As for the new bug status, what does "Unfortunate" status mean?

Comment 4:

"Unfortunate" means that we aren't going to make any changes.  The bug is closed.

Comment 5:

perhaps, it might be an api design flaw but we think that trying to control address
family A protocol stack by using address family B control knob (e.g., consumer, i mean
normal, socket, routing socket, sysctl, blah blah) is waste of time. also this
functionality is not supported on BSD variants. what synchronicity! see
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193246.
in this case you made an AF_INET6 w/ IPV6_ONLY=0 socket using ListenUDP because you
passed "udp".  A simple fix would be;
s/ListenUDP("udp"/ListenUDP("udp4"/
fwiw:
http://godoc.org/code.google.com/p/go.net/ipv4
http://godoc.org/code.google.com/p/go.net/ipv6

Labels changed: removed release-go1.4.

Status changed to Invalid.