Re: [go-nuts] Help with code reproducing a change in Go 1.15 CL 229578
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.
Re: [go-nuts] Help with code reproducing a change in Go 1.15 CL 229578
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/CAOyqgcXL-2A5yCBO8bDfyYfZMxuepg3e0J0koLHVsDYGgzLbrg%40mail.gmail.com.
[go-nuts] Help with code reproducing a change in Go 1.15 CL 229578
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. Thank you. -- 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/48f7e966-80d9-4d47-9932-1fbd5d5476adn%40googlegroups.com.
