Help with code reproducing a change in Go 1.15 CL 229578
101 views
Skip to first unread message
Florin Pățan
Jun 18, 2020, 4:54:03 AM6/18/20
to golang-nuts
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.
> 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.
Ian Lance Taylor
Jun 19, 2020, 1:13:37 AM6/19/20
to Florin Pățan, golang-nuts, Matthew Dempsky
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
Florin Pățan
Jun 21, 2020, 11:58:16 PM6/21/20
to golang-nuts
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:
Reply all
Reply to author
Forward
0 new messages