Hi, not an expert, but.
On Sat, Feb 27, 2021 at 11:19 PM Reto <[email protected]> wrote: > Now, as far as I can tell this forces non stdlib packages to adhere to > exactly that. > As far as I can tell x/sys is just a common namespace for the go authors, > but > as far as the compiler itself is concerned, that's a normal module not the > stdlib. > Or is this a wrong assumption? > I think you are correct in that the compiler does not give `x/sys` special treatment. However, `x/sys` is still somewhat special, in that, as its maintained by the Go team, they can make sure that `x/sys` stays up to date with regards to implementation details. That is, the documentation of the `unsafe` rules is more strict than it needs to be currently, to reserve the right to change the implementation in the future. And `x/sys` can use a more lenient interpretation, because if that implementation changes, it will be changed in lockstep. Furthermore, I'm not sure that the compiler gives `syscall` special treatment either. At least a cursory grep through `cmd/compile` for "syscall" seems to give few hits. The most relevant seems https://github.com/golang/go/blob/release-branch.go1.16/src/cmd/compile/internal/gc/esc.go#L386 which notably isn't restricted to `syscall` - it applies to any function, AIUI. This could basically mean that while the rule *states* "passing to syscall.Syscall", it actually exempts any call, because the special casing has not been done yet. But a future version *might*, so the rule still is more specific. So, in short: 1. yes, technically `x/sys` is not `syscall`, but you should probably treat them as the same thing, functionally. Maybe the `unsafe` docs should reflect that. 2. the rules are more restricted than what the implementation currently allows. 3. `x/sys` can follow the rules-as-implemented, because if the implementation changes, so will `x/sys` - stdlib or not. > > Reason I ask is because the code in x/sys clearly violates that rule. > > in unix/ioctl.go there's > > ``` > // IoctlSetPointerInt performs an ioctl operation which sets an > // integer value on fd, using the specified request number. The ioctl > // argument is called with a pointer to the integer value, rather than > // passing the integer value directly. > func IoctlSetPointerInt(fd int, req uint, value int) error { > v := int32(value) > return ioctl(fd, req, uintptr(unsafe.Pointer(&v))) > } > ``` > > and the declaration of ioctl in zsyskall_linux.go: > > ``` > func ioctl(fd int, req uint, arg uintptr) (err error) { > _, _, e1 := Syscall(SYS_IOCTL, uintptr(fd), uintptr(req), > uintptr(arg)) > if e1 != 0 { > err = errnoErr(e1) > } > return > } > ``` > > Now, for starters ioctl includes a pointless conversion of a uintptr to a > uintptr, > for the arg parameter can anyone tell me why? > > Second (and this is my actual question), isn't that in violation of the > unsafe > constraints cited above? > > IoctlSetPointerInt clearly converts a unsafe.Pointer to a uintptr and > *doesn't* > directly call syscall.Syscall. > > Why is this valid? > > Thanks in advance. > > Regards, > Reto > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/20210227221836.kgkn4xskg4xe7gsk%40feather.localdomain > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfE5pC4uiC%2B5D%2Bb2sw4Qb3HWKmKmq7Haa6HF1GLyuHM15g%40mail.gmail.com.
