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

go version go1.10.3 windows/amd64

Does this issue reproduce with the latest release?

Yes, 1.10.3 is the latest release.

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

(Irrelevant)

set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\delthas\AppData\Local\go-build
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\delthas\go
set GORACE=
set GOROOT=C:\Programs\Go
set GOTMPDIR=
set GOTOOLDIR=C:\Programs\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\delthas\AppData\Local\Temp\go-build595515002=/tmp/go-build -gno-record-gcc-switches

What did you do?

Minimal working example: https://play.golang.org/p/aFzB44u87fO
This playground example only works on Linux (so it works in the playground). Run it on a Windows machine to see the bug.

On Windows, send a zero-length-payload UDP packet and try to read it.

What did you expect to see?

I would expect to see the same behaviour as on Linux, which is that the packet is received.

What did you see instead?

The packet is not received and the read timeouts.

This bug is due to a payload length check in internal/poll/fd_windows.go that returns early before any WSAsendto call is done.

This check was added in the first implementation of this method in this commit in 2010.

There is a test supposed to cover this specific case: TestUDPZeroBytePayload in net/udpsock_test.go but it is "broken" on Windows: the test sends a zero-byte-payload and reads it with ReadFrom, and then sends another packet and reads it with Read. A comment reads that for the former case the ReadFrom should return with err == nil, and in the latter case the Read should return with a timeout error, however it does not actually check if this is the case and accepts timeouts for both cases. And on Windows, the two cases return with a timeout error, rather than the expected behaviour, because no actual packet is sent because of the check linked above.

A simple fix for this is to remove the check, and update the test to actually check if there is no timeout error in the ReadFrom case.

Can I open a pull request to fix this?