proposal: fmt: %p should accept uintptr #41495
Comments
ianlancetaylor
changed the title
|
CC @robpike |
|
#28865 is somewhat related, I think. |
|
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. |
|
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". |
|
It sounds like %#x is fine. |
|
Adding to minutes this week, but this seems headed for a likely decline based on the conversation. |
|
Based on the discussion above, this seems like a likely decline. |
|
No change in consensus, so declined. |
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.)
The text was updated successfully, but these errors were encountered: