https://github.com/golang/go/issues/11469 / https://go.googlesource.com/gofrontend/+/a850225433a66a58613c22185c3b09626f5545eb%5E!/ fixed gccgo tip to match what Go 1.5 does for the type of syscall.RawSockaddr.Data on ppc64le, which sounds good, but it means that the type is different from previous releases of gccgo on ppc64le, which means that programs that used to compile now don't, including docker: https://launchpadlibrarian.net/214319094/buildlog_ubuntu-wily-ppc64el.docker.io_1.6.2~dfsg1-1ubuntu4_BUILDING.txt.gz I don't know that docker can be changed in a way that will build with both new and old gccgo, which seems pretty unfortunate. At least changing the Go 1.5 type would allow that, but it's way too late for that.
I can't win. I deeply do not care about this type. Please sort it out with Lynn Boger. Thanks.
I was asked to make this fix to gccgo. A corresponding Docker fix is needed which is described here https://github.com/docker/libcontainer/pull/625. It is unfortunate it introduces an incompatibility which means that new Docker source can't be built with older gccgo compilers, but this is a bug and could lead to incorrect execution. It is assuming the field is signed when it should be treated as unsigned.
I don't think there is any risk of incorrect execution here. Nothing is going to care whether these bytes are signed or not.
I'll admit I'm not familiar with how this field could ever be used. But you are saying that no code will ever try to do a compare with this field when has a value greater than 127? If it did then it would get the wrong result because of the sign. In my opinion it is better to fix it now instead of wait until someone potentially hits a problem with it, when it will cost a lot more to investigate and fix. Especially since go 1.5 in golang is correct. Yesterday I got another (unrelated) question about the granularity of gccgo build tags. Seems like a more precise gccgo build tag would help here.
I am indeed saying that no code is ever going to do a less-than or greater-than comparison with the bytes in an IP address. Not that that has much to do with what we should do here. I'm just saying that the possibility of code that behaves incorrectly because these bytes are signed or unsigned is not an issue. It won't happen and we should not worry about it. What matters is whether programs compile or not.
I am working with our Docker team to provide a source change that will compile with old and new gccgo.
GCC 5.3 is being released, adjusting target milestone.
This fix is already in the gcc 5 branch commit r226595. It was tracked in the golang issues database https://github.com/golang/go/issues/11469.
Closing.