On Fri, Jun 4, 2021 at 5:23 AM Robert Engels <reng...@ix.netcom.com> wrote: > > I was referring to the “special cases” in this section > https://golang.org/cmd/cgo/ - wouldn’t all of these uintptr be stable?
The cgo tool gets special treatment: each cgo call is permitted to pin a known number of pointers. There is some background at https://go.googlesource.com/proposal/+/refs/heads/master/design/12416-cgo-pointers.md. There is a similar exception for calls to syscall.Syscall, documented at https://golang.org/pkg/unsafe/#Pointer. These mechanisms are specific to those uses, and don't apply to all pointers in general. Ian > On Jun 4, 2021, at 12:25 AM, Ian Lance Taylor <i...@golang.org> wrote: > > On Thu, Jun 3, 2021 at 9:13 PM Robert Engels <reng...@ix.netcom.com> wrote: > > > Doesn’t that depend on what the uintptr refers to? Eg if it was allocated off > heap to begin with then it should be stable and computing a hash on it is > valid. > > > That is true in current implementations, but Go, the language, does > not guarantee that pointers will never move. > > Ian > > > On Jun 3, 2021, at 9:42 AM, 'Axel Wagner' via golang-nuts > <golang-nuts@googlegroups.com> wrote: > > > > > On Thu, Jun 3, 2021 at 4:19 PM christoph...@gmail.com > <christophe.mees...@gmail.com> wrote: > > > The documentation doesn’t specify that we can cast an uintptr into a uint64. > > > > Both are integer types, so they can be converted. You might be worried about > their respective sizes and you are correct that the spec does not guarantee > that a uintptr is at most 64 bit. However, at least for any implementation I > know on any supported architecture, that's the case. If you *really* want to > make sure, you can do something like this: > > > func toBytes(v uintptr) []byte { > > var out []byte > > mask := ^uintptr(0) > > for mask != 0 { > > out = append(out, uint8(v)) > > v >>= 8 > > mask >>= 8 > > } > > return out > > } > > > But really, you can just trust that a uintptr fits into a uint64. Or, if you > want to future-proof, assume it's uint64, but guard by build tags to known > architectures (so it at least fails to compile if that assumption ever > changes). > > > To give some context, the application is for a cache with the hash key > computed over a pointer to a heap allocated struct. I need to store the > pointer in the cache entry to test for matching, but this would prevent the > struct to be garbage collected. Storing the pointer as an uintptr would do > the trick. > > > > This is problematic. The address of a value can change, so the uintptr would > change as well. So there is no guarantee that your hash stays the same, in > subsequent calls. > > Today, that usually doesn't happen, but there is no guarantee it stays that > way. If you are willing to assume that it doesn't happen, you should > definitely also be willing to assume a uintptr fits into a uint64 > > > > > -- > > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/7983a13f-5bf6-4299-a598-1d023ec9a9e9n%40googlegroups.com. > > > -- > > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFsZNHLXcONF9C6Nadr6muUP_kgOJwM3QUXSZ0KxPnfYQ%40mail.gmail.com. > > > -- > > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/35E8DBC1-E067-4717-BFFF-18732D77B987%40ix.netcom.com. > > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWY%3DS%3DtriGaYtNK_4v4Nw5AAZBCFOY2hKyTHQ9guaaiTw%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUTUdpfcDDf9M2qez7-L4etcVYgWkzcxuOeidJbGV8H2A%40mail.gmail.com.
