Hello, > My understanding is the `zero` variable just provides a unique memory location, and any type, e.g. byte, would have worked just as well. Is this right?
Yes. > Was uintptr choosen for performance reasons? Or to guarantee alignment? None of the above. `uintptr` was chosen for being consistent with runtime.zerobase, which is also an uintptr. Before `runtime.zerobase` is used, it was `runtime.zeroObject`, which is a `byte`, that's the result of rewriting mallocgc from C -> Go. In the mallocgc C source, the zerobase is defined as an uintptr: extern uintptr runtime·zerobase; Then in the process of support for auto-generating Go constants from the C definitions, duplicated constants were removed, prevent out of sync between C and Go constants. The result is that zeroObject was removed and `runtime·zerobase` becomes `runtime.zerobase`. Last but not least, since unique.zero and rutime.zerobase represents the base memory address of 0-byte object, what's better than an uintptr? My 2 cents. On Thursday, November 28, 2024 at 6:21:06 PM UTC+7 Jochen Voss wrote: > Dear all, > > I am looking at the source code for the new "unique" package (just out of > curiosity). > One thing I did not understand: why is `zero` defined to be an `uintptr`? > > https://cs.opensource.google/go/go/+/master:src/unique/handle.go;l=16 > > My understanding is the `zero` variable just provides a unique memory > location, and any type, e.g. byte, would have worked just as well. Is this > right? Was uintptr choosen for performance reasons? Or to guarantee > alignment? > > Many thanks, > Jochen > -- 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 visit https://groups.google.com/d/msgid/golang-nuts/8b8b7bb4-ec06-4ff3-8261-a695555a51c7n%40googlegroups.com.
