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.
> 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.
