On Fri, Jun 4, 2021 at 10:00 AM Robert Engels <reng...@ix.netcom.com> wrote: > > I was thinking of using C.malloc to create off heap structures. The uintptr > to those structs should be stable and can be used as map keys or values, > right? > > Not suggesting anyone should do that - just feasibility.
Yes, that works reliably. It's only Go pointers (pointers to memory allocated by Go) that can potentially change. Ian > > On Jun 4, 2021, at 10:38 AM, Ian Lance Taylor <i...@golang.org> wrote: > > > > 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/CAOyqgcWTQyHaaH_51%3DtyvXCzFuZjSkxbw8%3Db0yBWAf1hQf68Sg%40mail.gmail.com.
