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

proposal: fmt: %p should accept uintptr #41495

Open
seebs opened this issue Sep 19, 2020 · 4 comments
Open

proposal: fmt: %p should accept uintptr #41495

seebs opened this issue Sep 19, 2020 · 4 comments
Labels
Projects
Milestone

Comments

@seebs
Copy link
Contributor

@seebs seebs commented Sep 19, 2020

What version of Go are you using (go version)?

1.15

Does this issue reproduce with the latest release?

y

What operating system and processor architecture are you using (go env)?

N/A

What did you do?

fmt.Printf("%p", stringHeader.Data)

What did you expect to see?

A pointer value.

What did you see instead?

A fmt warning that %p got a non-pointer.

Rationale: It's true that uintptr is an integer-like thing rather than a pointer-like thing, but it's explicitly the type of integer which is used to represent pointers. It's certainly possible to just add the extra conversion everywhere, but I don't think it makes anything clearer, safer, or better. Allowing %p for uintptr shouldn't break any code except possibly "tests that check for getting that diagnostic" which seems like an edge case.

In the absence of moving GC, etc, I'd want %p to print a uintptr and the corresponding unsafe.Pointer identically.

(As a secondary issue, I would also sort of like %p to work on strings, printing the address of their backing store, but I'm enough less convinced of that that I'm leaving it as a parenthetical.)

@ianlancetaylor ianlancetaylor changed the title %p should accept uintptr proposal: fmt: %p should accept uintptr Sep 19, 2020
@gopherbot gopherbot added this to the Proposal milestone Sep 19, 2020
@gopherbot gopherbot added the Proposal label Sep 19, 2020
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Sep 19, 2020

@ianlancetaylor ianlancetaylor added this to Incoming in Proposals Sep 19, 2020
@mvdan
Copy link
Member

@mvdan mvdan commented Sep 20, 2020

#28865 is somewhat related, I think.

@robpike
Copy link
Contributor

@robpike robpike commented Sep 21, 2020

I'd rather that this not happen because uintptr is not a pointer, and the use of %p provides a modicum of type safety. If you want the hex you can always ask for it with %#x.

@seebs
Copy link
Contributor Author

@seebs seebs commented Sep 21, 2020

Yeah. This ties in somewhat with the occasional proposals for a slice-header-like-thing which contains an unsafe.Pointer instead of a uintptr. That said, I don't think there's a format specifier for uintptr that produces the same results as %p -- because %p can print "nil".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Proposals
Incoming
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.