-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
x/sys/windows: error codes for HRESULTs should be int32, not Handle #48736
Comments
I don't see any references to |
What @ianlancetaylor said. @dblohm7 please, show us the code. Thank you. Alex |
fails to compile with:
Notice that |
Thanks for explaining @dblohm7. I agree, These consts type is Also if I google, I find both say Int32.
Thank you. Alex |
On 64bit machines, this code might not work as expected: r, _, e := procDwmFlush.Call()
if windows.Handle(r) != windows.S_OK {
return fmt.Errorf("DwmFlush failed: %w", e)
}
return nil since, IIUC, EDIT: NVM, |
So I suggest these:
|
The error value are defined as windows.Handle (64bit) in golang.org/x/sys/windows, but an actual type should be HRESULT (32bit). This causes an issue that a returning value from a Windows API was recognized as a non-zero error value though the value was not an error, when the value's lower 32-bits are all zero. See also golang/go#48736 (comment) Updates #2113
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Tried to check the return code of a Windows syscall, known to be an
HRESULT
.What did you expect to see?
I expect to be able to do things that I can typically do with
HRESULT
s in C++, like check if they are negative (equivalent to the Windows SDK'sFAILED
macro), or compare my hresult value to a knownHRESULT
error code without the compiler complaining about type mismatches.In Microsoft's Windows SDK for C and C++,
HRESULT
s aretypedef
'd asLONG
, which on Windows is always anint32
. Further details as to whyHRESULT
s are not actually handles are outlined by Raymond Chen on his blog.What did you see instead?
Compile errors due to type mismatches, because error codes for
HRESULT
s are defined as having typeHandle
, which in turn is defined asuintptr
. Error codes forHRESULT
s should beint32
.The text was updated successfully, but these errors were encountered: