-
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
syscall: GetStartupInfo on Windows checks nonexistent return code #31316
Comments
/cc @alexbrainman |
Yes, I agree. Thank you very much for reporting. If I would add this function again, I would have it return nothing, like func GetStartupInfo(startupInfo *StartupInfo) But I don't think we could change function signature. Can we @ianlancetaylor ? If we have to keep it as is func GetStartupInfo(startupInfo *StartupInfo) error than we need to decide what to return. We could always return nil. Alternatively we could return what GetLastError Windows API returns. I am not sure which approach is better. Regardless, we will need new test with this change, because GetStartupInfo is not used anywhere in standard library. So we should at least somehow test it. And we should, probably, copy our solution into golang.org/x/sys/windows package too. Alex |
GetLastError() is going to just be some random number, and/or what it was
before you made the call. It's better to just return nil.
…On Tue, Apr 9, 2019 at 5:50 AM Alex Brainman ***@***.***> wrote:
Yes, I agree. Thank you very much for reporting.
If I would add this function again, I would have it return nothing, like
func GetStartupInfo(startupInfo *StartupInfo)
But I don't think we could change function signature. Can we
@ianlancetaylor <https://github.com/ianlancetaylor> ?
If we have to keep it as is
func GetStartupInfo(startupInfo *StartupInfo) error
than we need to decide what to return.
We could always return nil.
Alternatively we could return what GetLastError Windows API returns.
I am not sure which approach is better.
Regardless, we will need new test with this change, because GetStartupInfo
is not used anywhere in standard library. So we should at least somehow
test it.
And we should, probably, copy our solution into golang.org/x/sys/windows
package too.
Alex
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#31316 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AABQcIgC5To2qH7phaxDPYXcFuBY8f4eks5vfGJYgaJpZM4cgiOP>
.
|
How do you know? Value returned by GetLastError is set during GetStartupInfo implementation.
Maybe. Alex |
I don't think we should change the function signature of |
It’s standard for windows functions to not change GetLastError state if
they don’t return an “error” status value. Hence the pattern of only
returning the error code if the status code is an error.
Since this function is documented to never fail, it seems clear that it has
undefined behaviour around setting GetLastError, and well-documented
behaviour of not setting any error code.
Also, if it was setting GetLastError to zero on success, I would not have
experienced the problem (random error codes returned by the Go function)
that led me to file this bug in the first place.
…On Wed, Apr 10, 2019 at 08:52 Ian Lance Taylor ***@***.***> wrote:
I don't think we should change the function signature of GetStartupInfo,
but it would fine to make it always return nil if that is appropriate.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#31316 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AABQcEYvbEc9KpUsa8BltNOa6OeIgeZrks5vfd6ZgaJpZM4cgiOP>
.
|
Thank you for replying. SGTM
I never seen any of Microsoft Windows API implementations source code, so I would not really know. But pretty much every Windows API changes GetLastError value. So, if the implementation calls other Windows APIs, that would make GetLastError change. But maybe GetStartupInfo implementation does not call any other APIs. Anyway, it is not important, because we all agreed to have GetStartupInfo return nil. Would you like to send a change? The change would need a test too. Alex |
Change https://go.dev/cl/520275 mentions this issue: |
Change https://go.dev/cl/520295 mentions this issue: |
Same as CL 520275 did in package syscall. For golang/go#31316 Change-Id: Ie9d8fed7f40b9e562534d5e91488b4ba1ac44f34 Reviewed-on: https://go-review.googlesource.com/c/sys/+/520295 TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]> Auto-Submit: Tobias Klauser <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Run-TryBot: Tobias Klauser <[email protected]>
What version of Go are you using (
go version
)?(cross compiling to Windows amd64)
Does this issue reproduce with the latest release?
The relevant code has not changed lately.
What did you do?
What did you expect to see?
err should always be nil, because according to https://technet.microsoft.com/en-us/ms683230(v=vs.90), "The Unicode version (GetStartupInfoW) does not fail."
What did you see instead?
Under some circumstances (eg. starting from cmd.exe), GetStartupInfo returns syscall.EINVAL. Under other circumstances (eg. starting from WSL's bash), it succeeds.
The implementation of GetStartupInfo() is:
So EINVAL should only happen if r1==0 && e1==0. As far as I can tell, GetStartupInfoW() is never supposed to return any value, so checking r1 is not the right thing to do here.
Indeed, if I copy this function but disable the error check, the StartupInfo struct seems to be filled correctly even in the error case. So I think the correct fix is to simply stop checking the return code.
If you want to be paranoid, you could verify that StartupInfo.Cb is set to a nonzero value after the syscall finishes.
The text was updated successfully, but these errors were encountered: