net: LookupPort("tcp", "") can produce inconsistent results between cgo and Go netdns

[siebenmann]

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.

[ianlancetaylor]

CC @bradfitz @mdempsky @mikioh

[bradfitz]

We can hard-code a rule that "" means 0 early in LookupPort, but that doesn't mean it was always consistent before. Windows and Plan 9 probably did different things.

Testing that now in CL 17755.

[bradfitz]

Results:

https://go-review.googlesource.com/#/c/17755/

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.

[gopherbot]

CL https://golang.org/cl/17755 mentions this issue.

[gopherbot]

CL https://golang.org/cl/31950 mentions this issue.