Oh, forgot to mention: The code I linked to has been moved or removed in master, vs. go 1.16. So the time of "when the implementation changes" might be "now" :)
On Sun, Feb 28, 2021 at 2:11 AM Axel Wagner <[email protected]> wrote: > 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/CAEkBMfFb3zD78ejNAq3G7grWd9z8JrO%2BPhH5v2nNwPF3046bGg%40mail.gmail.com.
