syscall usage
dnwe opened this issue · 4 comments
Having encountered some unnecessary syscall usage on a recent PR review, it seems like there's a couple of areas for possible semgrep/ruleguard coverage around the use of the deprecated syscall package
- Low-level syscall funcs should be replaced via the cross-platform equivalent os, time, net etc. func calls
- If a syscall is truly needed then they should be calling the func in the appropriate non-deprecated golang.org/x/sys pkg instead?
This sounds great. Do you have a specific example we could add that has a low false-positive rate?
Simple things like syscall Chmod, Chown and Setenv, Unsetenv, Clearenv mapping to the os versions would be a good start I think. I’m not sure there would ever be a good reason to use those basic ones outside the std library
One interesting conundrum are the various const values in syscall such as S_IRUSR and whether they are always the same between golang.org/x/sys/unix and golang.org/x/sys/windows
That sounds reasonable. I'll try to write up a rule for some of these.
So far, the only “need” I've seen for syscall
as opposed to golang.org/x/sys/unix
and friends is the syscall.RawConn
interface. And it's not really a need, because thanks to the way Go interfaces work, you can redefine a local copy of that interface.
syscall.Errno
could be another one, but I'm pretty sure that by now most of these are mapped to os.ErrNotExist
and such, and so can be detected using a simple errors.Is
.