Hi Ian, Thank you for your reply.
At the moment, I don't have any data about this. The question raised from the fact that the language in the documentation suggests that a compiler error would occur, at least to me as a user with English as a second language. So, when I created some test scenarios to know if we should add similar checks for this in GoLand, I was a bit surprised that there's nothing that would happen, either with `go build` or with `go vet`. I'll see if I can find any such usages and report back here. For now, it seems we can omit to create such a check in the IDE / other static analysis tools. Thank you, Florin On Friday, June 19, 2020 at 8:13:37 AM UTC+3 Ian Lance Taylor wrote: > On Thu, Jun 18, 2020 at 1:54 AM Florin Pățan wrote: > > > > According to the Go 1.15 documentation, the change introduced in > https://golang.org/cl/229578 should change the program behavior, and > users are expected to perform modifications to their code. > > > > > Package unsafe's safety rules allow converting an unsafe.Pointer into > uintptr when calling certain functions. Previously, in some cases, the > compiler allowed multiple chained conversions (for example, > syscall.Syscall(…, uintptr(uintptr(ptr)), …)). The compiler now requires > exactly one conversion. Code that used multiple conversions should be > updated to satisfy the safety rules. > > > > After reading that paragraph, I expect that the compiler fails to > compile code after that change. When running `go build` or `go build > -gcflags="-d=checkptr"` neither produce a failure. I used `go vet`, and > that doesn't catch this change either. > > > > The example I used is https://play.golang.org/p/a0B4kxLEAjb. > > > > Perhaps I failed to construct a correct example, in which case help > would be appreciated. > > > > I was not sure if this belongs to the mailing list or the issue tracker, > so I started here. > > What has changed is that the compiler does not keep multiply-casted > pointers live across the call to syscall.Syscall. > > Our assumption was that nobody actually wrote code like that. Why > would they? Do you know of any real code that does this? If there is > no real code, then it doesn't seem worth spending the time to write > checks. If we were going to do that, we might as well instead spend > the time to let the code continue to work. > > Ian > -- 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3545930b-1b40-44b3-89c7-3ba24a5be797n%40googlegroups.com.
