> Am 20.06.2024 um 14:12 schrieb Axel Wagner <axel.wagner...@googlemail.com>: > > On Thu, 20 Jun 2024 at 13:48, Oliver Eikemeier <eikeme...@fillmore-labs.com > <mailto:eikeme...@fillmore-labs.com>> wrote: > > I think you should acknowledge that the spec *is* already trying to be very > clear about this. The fact that you can poke holes in it is because writing a > spec unambiguously is hard.
I acknowledge that - that’s why I care in the first place and also - as mentioned - try not to be stubborn. Although the latter is not always easy in internet discussions, but I digress. > But the two quoted phrases are there in the best attempt to clearly state > that you can not rely on any assumptions about pointers to zero-sized > variables - within the somewhat abstract framework of the spec. Feel free to > propose a better one, I'm not actually arguing against that. Yeah, I’m still trying to understand the issue, the discussion helps, so thanks for that. > Am 20.06.2024 um 14:21 schrieb Robert Engels <reng...@ix.netcom.com>: > > I would add that I think the Go team should strive to remove as much > “implementation defined” or “undefined” from the spec as possible. Forgo the > optimizations. It’s this language that makes C++ such a pain to work with > especially in a cross platform manner. > > I think you can safely narrow the spec in this area without issue - since it > would have been very difficult to use anyway. Maybe some highly specialized > code that relied on a particular Go implementation might. What happens seems to be: a) In practice the runtime just uses pointers as memory addresses, so everything is fine there. b) Pointers (especially unsafe pointers) being address in memory (not only “a storage location for holding a value”) is not really specified, but sometimes useful. The standard runtime uses casting of unsafe pointer for multiple reasons. c) Pointers to zero sized variables have to point somewhere. Since the variable has zero size, some aliasing is easily possible. d) The optimizer is free to make assumptions about aliasing that sometimes don’t match the memory alignment during runtime, disagreeing with a). I’m not advocating against the optimizer making assumptions about aliasing that are not true, it seems useful to me. On the other hand you can do surprising constructs (Go Playground <https://go.dev/play/p/uad7uyxX8PX>): func f7() { var ( a struct{} b int aa = (*int)(unsafe.Pointer(&a)) ba = (*int)(unsafe.Pointer(&b)) ) println("&a:", aa, reflect.TypeOf(aa).String()) println("&b:", ba, reflect.TypeOf(ba).String()) *ba = 0 *aa++ println(*ba, aa == ba) *ba++ println(*aa, ba == aa) } &a: 0xc0000466f8 *int &b: 0xc0000466f8 *int 0 false 2 false There are definitely dragons. I might need some more time to think over this, but thanks to every participant for the useful input. Cheers Oliver -- 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/E0D19A9C-4434-4CEB-B154-B10CD3959A61%40fillmore-labs.com.
