-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: GetLastError always returns nil #41220
Comments
The idea is that the error will be returned by the call, so you should never to call So, if there is anything to do here, it's simply to document that there is no point to calling |
What Ian said - do not call GetLastError directly from your code - Go runtime calls GetLastError for you behind the scenes. It is pointless to call GetLastError from your Go code, because GetLastError changes every time you make new Windows API call. But Go runtime calls different Windows API at all times (for example to get memory or create threads). The fact that you don't see any Windows API calls in your code does not mean your program does not call Windows APIs. Go runtime also changes threads all the time. GetLastError is thread specific. So, if you call GetLastError from your code, you might be getting GetLastError value from another unrelated thread.
On lines 70-73 this function gathers GetLastError value right after Windows API is finished. Just use that value. Alex |
Sorry for bumping up more than 1-year-old thread. I understand that calling GetLastError is not the right way to get error. Then, I think it should be documented properly, such as "GetLastError will return always nil. Use return value of each API call instead", as suggested in previous comment. Maybe marking GetLastError as deprecated is also possible. |
As an alternative, I wonder if we could change the Go runtime to provide a stronger invariant that makes And perhaps That invariant might require more care in preserving and restoring error values in the runtime's signal handlers, although if signal-handler changes are needed for this invariant, they are probably also needed in order to avoid corrupting (CC @golang/windows) |
What would be the benefit of making runtime code and the documentation more complicated in comparison to just using the returned GetLastError value from original API call? See
from #41220 (comment) .
I am OK with that, if you feel strongly about it. But I don't think many people call GetLastError anyway. We can also just document not to use it. And explain the reason. Alex |
The benefit would be that callers can use |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Not tried, but I'm pretty sure it will.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
What did you expect to see?
Prints out error message describing 'module not found' twice.
What did you see instead?
According to https://golang.org/src/runtime/sys_windows_amd64.s , before calling actual DLL routine (line 58), last error information is erased (line 22-23). This makes syscall.GetLastError (and windows.GetLastError) completely meaningless,
The text was updated successfully, but these errors were encountered: