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: ParseIP always returns an IP in ipv6 ipv4-mapped address format #8985

gopherbot opened this issue Oct 23, 2014 · 5 comments

net: ParseIP always returns an IP in ipv6 ipv4-mapped address format #8985

gopherbot opened this issue Oct 23, 2014 · 5 comments


Copy link

@gopherbot gopherbot commented Oct 23, 2014

by cserveny.tamas:

What does 'go version' print?
go version go1.3 linux/amd64

What steps reproduce the problem?
If possible, include a link to a program on

What happened?

ParseIP tries to parse it as an IPv4 address, but fails. Apparently IPv6 parser accepts
IPv4 addresses and formats them accordingly, but there is no way to determine whether
the IP is 4 or 6 this way.

What should have happened instead?

I would have expected len = 4. The intent of the code was clearly this.
Test case ip_test.go is broken , because IPv4 equals the correct IPv6 notation so the
automated tests did not catch this.

Please provide any additional information below.

It would be good to be able to determine the type of address with len, better even if go
would provide IsIPv4 method.
Copy link

@OneOfOne OneOfOne commented Oct 23, 2014

Comment 1:

While having that function would be handy, it's trivial to check if it's IPv4 or not:
func IsIPv4(ip net.IP) bool {
    return ip.To4() != nil
Copy link

@ianlancetaylor ianlancetaylor commented Oct 23, 2014

Comment 2:

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

Copy link

@gopherbot gopherbot commented Oct 24, 2014

Comment 4 by cserveny.tamas:

Just out of curiosity, in case I would not use such a handy function, would it grow my
output binary? Why Go does not want to have an API which is easy to use?
Go is lacking many such handy methods and the reason is always the same: it is easy to
implement for yourself.
What is the rationale behind this?
Copy link

@ianlancetaylor ianlancetaylor commented Oct 24, 2014

Comment 5:

A function that is not used does not increase the size of the output binary.  (A method
that is not used does increase it in some cases.)
People using a package need to be able to understand and use all the functions in the
package.  When considering whether to add a new function, we need to consider not only
whether the function is handy, but also how much extra cognitive load it imposes on
every user of the package.  Adding a bunch of trivial but handy functions is not free;
it means that every user of the package needs to know about those functions and
understand what they do.  In many cases we prefer to lean in the direction of providing
the minimum set of functions required so that you can do whatever you need.  A minimum
set of functions can be fully understood.
@gopherbot gopherbot added new labels Oct 24, 2014
@bradfitz bradfitz modified the milestone: Go1.5 Dec 16, 2014
@rsc rsc removed the repo-main label Apr 14, 2015
Copy link

@mikioh mikioh commented May 21, 2015

Marking this issue as working as intended. There still are various address family transition stuff:, and we need a type that can grab any IP address for supporting such transition features. Also we cannot provide such IsIPv4, IsIPv6 methods without application context. For example, what happens when an application treats IPv4-embedded IPv6 addresses as IPv4 addresses.

FWIW, this IETF v6ops thread,, might be interesting for some people.

@mikioh mikioh closed this May 21, 2015
@mikioh mikioh modified the milestones: Unplanned, Go1.5 May 21, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants