No, because the Garbage Collector knows that they are pointers and would
change the pointer in the map (and presumably its bucket) if it moved the
value. It's certainly not trivial to implement, but these are problems that
would have to be solved if the GC starts moving things around - because the
language allows to use pointers as keys, so we need to keep that safe.
On Fri, Jun 4, 2021 at 3:02 PM christoph...@gmail.com <
christophe.mees...@gmail.com> wrote:
> > That is true in current implementations, but Go, the language, does not
> guarantee that pointers will never move.
>
> That is what I thought, but it is allowed to use a pointer far map keys.
> And I have seen some programs/package using this feature.
> Apparently all these programs and packages would break if objects were to
> be moved around ?
>
> Le vendredi 4 juin 2021 à 07:25:11 UTC+2, Ian Lance Taylor a écrit :
>
>> On Thu, Jun 3, 2021 at 9:13 PM Robert Engels <ren...@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 <
>> golan...@googlegroups.com> wrote:
>> >
>> >
>> > On Thu, Jun 3, 2021 at 4:19 PM christoph...@gmail.com <
>> christoph...@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...@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...@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...@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/eea09044-6db3-450b-ba6e-0c31dd733681n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/eea09044-6db3-450b-ba6e-0c31dd733681n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAEkBMfFAgHJGuCpA5EaQXzXBUj4ifJoeNrJVYBzBc5%2Bfdxac2Q%40mail.gmail.com.
