Thank you for re-opening and answering the question. The original reason why I closed it was because after looking it up in the unsafe package documentation (as I was skimming through source-code originally) it states in Section 2, Paragraph 4 <https://golang.org/pkg/unsafe/#Pointer> (I feel like a lawyer stating it this way), that:
"A uintptr is an integer, not a reference. Converting a Pointer to a uintptr creates an integer value with no pointer semantics. Even if a uintptr holds the address of some object, the garbage collector will not update that uintptr's value if the object moves, nor will that uintptr keep the object from being reclaimed." However, the whole issue of casting being handled at compile-time is comforting, as there shouldn't be any overhead whatsoever to the runtime. On Monday, June 20, 2016 at 12:15:07 PM UTC-4, Jan Mercl wrote: > > On Mon, Jun 20, 2016 at 5:45 PM Kyle Stanly <thei...@gmail.com > <javascript:>> wrote: > > The GC is precise, it will not confuse an integer and a pointer. > > Keeping a a pointer in a uintptr as a "reference" to something is safe iff > it will never be casted back to a pointer. I think this means that the safe > case is useless. > > > Finally, is there any implicit overhead from casting to and from a > uintptr (and unsafe.Pointer)? > > There are no casts in Go. Converting between a uintptr and a > unsafe.Pointer is a compile time typechecking issue, it has no runtime cost > - provided crashing one's machine is not considered a runtime "cost" ;-) > > > -- > > -j > -- 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. For more options, visit https://groups.google.com/d/optout.
