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

unsafe: wrong type mentioned in explanation #24115

Closed
dotaheor opened this issue Feb 25, 2018 · 4 comments
Closed

unsafe: wrong type mentioned in explanation #24115

dotaheor opened this issue Feb 25, 2018 · 4 comments
Labels
Documentation FrozenDueToAge help wanted NeedsFix The path to resolution is known, but the work has not been done.

Comments

@dotaheor
Copy link

In this usage hdr.Data is really an alternate way to refer to the underlying pointer in the slice header, not a uintptr variable itself.

slice should be string

@ysmolsky
Copy link
Member

ysmolsky commented Feb 25, 2018

I understand this as hdr.Data refers to the underlying pointer in the slice after the assignment to hdr.Data. Notice p in uintptr(unsafe.Pointer(p)):

var s string
hdr := (*reflect.StringHeader)(unsafe.Pointer(&s)) // case 1
hdr.Data = uintptr(unsafe.Pointer(p))              // case 6 (this case)
hdr.Len = n

In this usage hdr.Data is really an alternate way to refer to the underlying pointer in the slice header, not a uintptr variable itself.

@ALTree ALTree changed the title unsafe: wring type mentioned in explainations. unsafe: wrong type mentioned in explanation Feb 25, 2018
@FiloSottile
Copy link
Contributor

The line should still say string, not slice, because hdr.Data refers to the string header.

However yeah there is also a phantom pointer p to an object (array?) of length n that the string is being redefined to, which makes the doc very hard to read. I would like to see an explicit p added.

@FiloSottile FiloSottile added help wanted NeedsFix The path to resolution is known, but the work has not been done. labels Feb 25, 2018
@ianlancetaylor
Copy link
Contributor

I can't come up with a reasonable way to define p and n in this example. The only plausible case is calling a cgo function, but I don't want to have to refer to cgo here.

@gopherbot
Copy link

Change https://golang.org/cl/96983 mentions this issue: unsafe: fix reference to string header

@golang golang locked and limited conversation to collaborators Feb 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Documentation FrozenDueToAge help wanted NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

6 participants