Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
siebenmann opened this issue Dec 14, 2015 · 5 comments

Comments

Projects
None yet
4 participants
@siebenmann
Copy link

commented Dec 14, 2015

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 ianlancetaylor added this to the Go1.6 milestone Dec 14, 2015

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Dec 14, 2015

@bradfitz

This comment has been minimized.

Copy link
Member

commented Dec 14, 2015

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

This comment has been minimized.

Copy link
Member

commented Dec 14, 2015

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

This comment has been minimized.

Copy link

commented Dec 14, 2015

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

@bradfitz bradfitz closed this in 5a88e54 Dec 14, 2015

@gopherbot

This comment has been minimized.

Copy link

commented Oct 25, 2016

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

@golang golang locked and limited conversation to collaborators Oct 25, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.