You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
x/sys: stdio handle inheritance getting changed after dynamic loading of a DLL #52498
I agree that few people actually use thatStdin. However, the init function will still always initialize those variables, which has the process-wide side effect of clearing the inheritance flags from the standard handles, so it's definitely a bug that needs fixing.
On the other hand, if it's really the case that nobody uses the identifiers from x/sys, then perhaps the best action would be to remove the declarations entirely?
the best action would be to remove the declarations entirely
I don't think we can remove the declarations. We always try not to break people code. So even if one person is using this code, we should try and fix them.
-bash-4.2# ls
AUTHORS codereview.cfg CONTRIBUTING.md CONTRIBUTORS cpu execabs go.mod internal LICENSE PATENTS plan9 README.md unix windows
-bash-4.2# go test ./...
warning: GOPATH set to GOROOT (/usr/local/go) has no effect
ok golang.org/x/sys/cpu (cached)
ok golang.org/x/sys/execabs 0.016s
ok golang.org/x/sys/internal/unsafeheader (cached)
ok golang.org/x/sys/unix 0.612s
ok golang.org/x/sys/unix/internal/mkmerge (cached)
? golang.org/x/sys/windows/mkwinsyscall [no test files]
Activity
thanm commentedon Apr 22, 2022
Sounds like a good change to make.
Want to send a CL?
alexbrainman commentedon Apr 23, 2022
I doubt anyone uses
golang.org/x/sys/windows.Stdin. People use eitheros.Stdinorsyscall.Stdin.But sure. We should change
golang.org/x/sys/windowscode too.@aayush13890 do you want to send a change?
Here is how to contribute
https://go.dev/doc/contribute
Alex
rkennedy commentedon Apr 23, 2022
I agree that few people actually use that
Stdin. However, theinitfunction will still always initialize those variables, which has the process-wide side effect of clearing the inheritance flags from the standard handles, so it's definitely a bug that needs fixing.On the other hand, if it's really the case that nobody uses the identifiers from x/sys, then perhaps the best action would be to remove the declarations entirely?
aayush13890 commentedon Apr 25, 2022
@alexbrainman @thanm any suggestions on the @rkennedy 's question above? I will go through the steps to contribute in the meanwhile. Thanks!
alexbrainman commentedon Apr 26, 2022
@aayush13890 if you refer to
I don't think we can remove the declarations. We always try not to break people code. So even if one person is using this code, we should try and fix them.
Alex
gopherbot commentedon Apr 27, 2022
Change https://go.dev/cl/402714 mentions this issue:
windows: do not change stdio handle inheritanceaayush13890 commentedon Apr 27, 2022
@alexbrainman @rkennedy @thanm I have submitted the CL. I am making a change to this repo for the first time. Please let me know if I am missing anything. Also, how do I build the code and run all the tests inside
sys/windows folder in my source code (https://github.com/golang/sys/tree/master/windows)?
I tried running:
-bash-4.2#pwd
/root/Aayush/go-repos/go-sys/sys
-bash-4.2# ls
AUTHORS codereview.cfg CONTRIBUTING.md CONTRIBUTORS cpu execabs go.mod internal LICENSE PATENTS plan9 README.md unix windows
-bash-4.2# go test ./...
warning: GOPATH set to GOROOT (/usr/local/go) has no effect
ok golang.org/x/sys/cpu (cached)
ok golang.org/x/sys/execabs 0.016s
ok golang.org/x/sys/internal/unsafeheader (cached)
ok golang.org/x/sys/unix 0.612s
ok golang.org/x/sys/unix/internal/mkmerge (cached)
? golang.org/x/sys/windows/mkwinsyscall [no test files]
windows: do not change stdio handle inheritance