Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
net: LookupPort("tcp", "") can produce inconsistent results between cgo and Go netdns #13610
On at least Linux, a cgo net.LookupPort("tcp", "") will succeed and return a port of 0 while a native Go version of the same query will fail with 'unknown port tcp/'. You might think that this is a silly thing to look up, but it can come up indirectly if you use eg net.ResolveTCPAddr("tcp", "IP:") to resolve something that you will set in a net.Dialer as the LocalAddr, with the intended meaning of the port being 'any port'.
Because net.LookupPort() may choose at runtime whether or not to use cgo or pure Go lookups, the overall effect of this is to enable code that is silently system dependent; it will work on some machines, ones where the resolv.conf or nsswitch.conf configuration forces cgo, and fail on others, where Go can use the pure Go versions. I think it would be better to either always work (by explicitly supporting a blank port being port 0) or always fail (by explicitly checking for and rejecting a blank port, and documenting that for 'give me any port' you should specify ':0', at least for TCP and UDP). The latter is probably easier.
It does pass at least on Windows. It used to pass on Go 1.4.2 on Unix, and passes with cgo, as you reported.
Plan 9 didn't report success for an empty port string, but Plan 9 doesn't get to set precedent for this.