Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spec: no rules for converting between unsafe.Pointer and *T #68086

Open
Merovius opened this issue Jun 20, 2024 · 5 comments
Open

spec: no rules for converting between unsafe.Pointer and *T #68086

Merovius opened this issue Jun 20, 2024 · 5 comments
Assignees
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.

Comments

@Merovius
Copy link
Contributor

Merovius commented Jun 20, 2024

Based on a golang-nuts thread.

Consider this program:

var (
	x struct{}
	y *int = (*int)(unsafe.Pointer(&x))
)
*y = 42

The spec says about unsafe.Pointer:

A Pointer is a pointer type but a Pointer value may not be dereferenced. Any pointer or value of core type uintptr can be converted to a type of core type Pointer and vice versa. The effect of converting between Pointer and uintptr is implementation-defined.

Notably, while this does specify that conversion between unsafe.Pointer and uintptr is implementation-defined, it doesn't contain the same caveat for conversion between unsafe.Pointer and other pointers (like *int in the example above). So the spec does not give any way to reason about the behavior of the above program - not even that it is implementation defined.

The unsafe.Pointer rules do of course rule that program out, so the implementation-defined rules do allow us to reason about the program. But, technically speaking, we are not giving it purview to do that.

I would propose to change "The effect of converting between Pointer and uintptr is implementation-defined" to "The effect of such conversions is implementation-defined".

@mauri870 mauri870 added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 20, 2024
@mauri870
Copy link
Member

@ruyi789
Copy link

ruyi789 commented Jun 20, 2024

You shouldn't use this API if you want to be safe, because that's how it's used and it doesn't report errors. That's the very practical value of it.

You might consider using it this way or staying away from it, but what's wrong with it?


func Generic_To[E any, T any](val *E, e *T) (r *T) {
	return (*T)(unsafe.Pointer(val))
}
func Generic_To2[E any, T any](val *E, e T) (r *T) {
	return (*T)(unsafe.Pointer(val))
}
func Generic_To3[E any, T any](val E, e T) (r T) {
	return *(*T)(unsafe.Pointer(&val))
}

@griesemer griesemer self-assigned this Jun 20, 2024
@griesemer
Copy link
Contributor

griesemer commented Jun 20, 2024

@Merovius We probably were (implicitly) assuming that since an unsafe.Pointer is a pointer type, any conversion between pointer types only changes the types but doesn't really "do" anything at runtime - which is of course what happens but we (probably) don't want to write that down, yet we need to write something about it. I think your suggestion seems fine, thanks.

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/593755 mentions this issue: spec: clarify prose about unsafe pointer conversions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

6 participants