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: Is net.IP.IsUnspecified() not specific enough? #19344

Closed
markdingo opened this issue Mar 1, 2017 · 6 comments

Comments

Projects
None yet
4 participants
@markdingo
Copy link

commented Mar 1, 2017

What version of Go are you using (go version)?

go version go1.8 darwin/amd64

But it's been this way for a long time.

What operating system and processor architecture are you using (go env)?

darwin_amd64 but all architectures.

What did you do?

Called net.IP.IsUnspecified() with an unassigned net.IP struct

If possible, provide a recipe for reproducing the error.

https://play.golang.org/p/GHc6PatP8i

What did you expect to see?

I expect any net.IP struct that does not contain a valid ipv4 or ipv6 address to be "unspecified".

What did you see instead?

IP structs that are neither ipv4 or ipv6 are accepted as "specified".

I think IsUnspecified() should check that the IP is a valid v4 or v6 length before testing against their respective zero values. The playground link show an implementation of IsUnspecified() that I think has more precise semantics.

@mikioh mikioh changed the title Is net.IP.IsUnspecified() not specific enough? net: Is net.IP.IsUnspecified() not specific enough? Mar 2, 2017

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Mar 2, 2017

The IsUnspecified method of IP is designed to report whether the IP is an unspecified IP address from IP addressing architecture point of view. In your example, an empty value of IP is not an unspecified IP address. For what it's worth, an unspecified IP address is used as a source address under certain cases on certain signaling protocols, as a wildcard identifier for exposed APIs, as a default route identifier for some applications, and as an entire IP address space on routing protocols.

I agree that the existing documentation is not kind for users. I guess that the go team welcomes any documentation fixes.

@markdingo

This comment has been minimized.

Copy link
Author

commented Mar 2, 2017

I agree that IsZero() addresses can be used, particularly as a Listen address, but the use case for the IsUnspecified() seems particularly narrow.

I did a quick web search and found just a couple of uses around using IsUnspecified() as a proxy for error detection - just as I mistakenly did - and actually incorrect usage where IsLocal() might have been better.

I guess the primary question is, what problem is IsUnspecified() trying to solve and the secondary question is, what is the correct way to test that an IP contains a valid address?

You almost wonder whether there might be an argument for IsListenable() and IsConnectable() functions.

(Yes, I know I can solve my problem with just a couple of lines of code, but this seems to be a missing piece of functionality that should be of general value to any function getting passed an IP).

@bradfitz bradfitz added this to the Go1.9Maybe milestone Mar 21, 2017

@bradfitz

This comment has been minimized.

Copy link
Member

commented Mar 21, 2017

In any case, these docs answer nobody's questions:

https://golang.org/pkg/net/#IP.IsUnspecified

IsUnspecified reports whether ip is an unspecified address.

Let's either:

  • make the function do what people expect (which maybe we can't do for go1compat reasons, but does anybody use this function?)
  • document it.

@bradfitz bradfitz modified the milestones: Go1.9, Go1.9Maybe Mar 21, 2017

@markdingo

This comment has been minimized.

Copy link
Author

commented Mar 21, 2017

As I mentioned in the initial post, I found a few code fragments that use the function, but most do so incorrectly. They made the same naive mistake I did of taking the word "specified" literally. That is, something unspecified cannot be used because it has no "specific" value.

That is, I took it to mean whether the address was usable or not.

Given go1compat, the best we can do is document IsUnspecified better and perhaps point the reader to more useful functions.

The sort of things I generally want to know about IP addresses are:

  • Can I use it as a source or destination address (ie, will bind() work)
  • Can it identify an end-point and is thus worthy of storing in a database

Many of the address-space attributes of IP addresses are well covered (linklocal, multicast, etc) but the aforementioned "application" layer semantics are not. So maybe the right approach is to think about this in terms of application layer semantics and then see what we end up with?

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Mar 21, 2017

aforementioned "application" layer semantics are not.

Yup, the same as #11772. I'll update the existing docs for clarification.

@mikioh mikioh removed their assignment Mar 27, 2017

@gopherbot

This comment has been minimized.

Copy link

commented Jun 6, 2017

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

@bradfitz bradfitz modified the milestones: Go1.9Maybe, Go1.9 Jun 13, 2017

@gopherbot gopherbot closed this in b88efc7 Jun 23, 2017

@golang golang locked and limited conversation to collaborators Jun 23, 2018

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.