x/sys/windows: FormatMessage can't accept a DLL handle on 64-bit systems

[actgardner]

1. What version of Go are you using (go version)?
   go1.3.3 windows/amd64
2. What operating system and processor architecture are you using?
   Windows x86-64
3. What did you do?
   Try to call syscall.FormatMessage with a DLL handle.

var flags uint32 = syscall.FORMAT_MESSAGE_ARGUMENT_ARRAY | syscall.FORMAT_MESSAGE_IGNORE_INSERTS | syscall.FORMAT_MESSAGE_FROM_HMODULE
libpdhDll := syscall.MustLoadDLL("pdh.dll")
buffer := make([]uint16, 300)

// Have to cast Handle, which is a uintptr, to a uint32 due to the signature of FormatMessage
syscall.FormatMessage(flags, uint32(libpdhDll.Handle), <some error number>, 0, buffer, nil)

1. What did you expect to see?
   FormatMessage should accept a syscall.Handle or a uintptr so the cast to uint32 doesn't have to happen.

5.What did you see instead?
FormatMessage returns an error because the truncated pointer doesn't point to a DLL.

[bradfitz]

Go 1.3.3 is old and unsupported. Please try with Go 1.4.2 or ideally Go tip and report back.

[actgardner]

The same issue clearly exists in master: https://github.com/golang/sys/blob/master/windows/zsyscall_windows.go#L476

go/src/syscall/zsyscall_windows.go

Line 243 in f9ed2f7

func FormatMessage(flags uint32, msgsrc uint32, msgid uint32, langid uint32, buf []uint16, args *byte) (n uint32, err error) {

edit: To be clear, the issue is just that msgsrc does an insane roundtrip from uintptr to uint32 back to uintptr, which doesn't make sense on 64-bit.

[minux]

The syscall package is frozen, but we can fix the problem in
x/sys/windows sub-repo instead.

[alexbrainman]

My mistake. I am 386 person.

Any suggestion on what to do about syscall.FormatMessage are welcome. I cannot see what we could do besides documenting the bug.

Alex

[alexbrainman]

@alanctgardner here https://go-review.googlesource.com/11165 is the change. Will that work for you?

Alex

[actgardner]

Looks good @alexbrainman, thanks for the fix!

[gopherbot]

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

[gopherbot]

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