> Am 20.06.2024 um 13:24 schrieb Axel Wagner <axel.wagner...@googlemail.com>:
> 
> We can see that 1. `unsafe.Pointer` is definitionally a pointer type, 2. in 
> your example, the two `unsafe.Pointers` do not point to the same variable and 
> do not have the value `nil` and 3. are not pointing at distinct zero-sized 
> variables. So their comparison should be `false`, which is what your example 
> observes.

Does it (Go Playground <https://go.dev/play/p/230UNKVQl0A>)?

func f5() {
        var (
                a  struct{}
                b  int
                aa = (*int)(unsafe.Pointer(&a))
                ba = (*int)(unsafe.Pointer(&b))
                eq = aa == ba
        )

        println("&a:", aa, reflect.TypeOf(aa).String())
        println("&b:", ba, reflect.TypeOf(ba).String())
        println("&a == &b:", eq)
        cmpIntPtr(aa, ba)
}

func cmpIntPtr(p1 *int, p2 *int) {
        fmt.Println("p1 == p2:", p1 == p2)
}

&a: 0xc0000466f8 *int
&b: 0xc0000466f8 *int
&a == &b: false
p1 == p2: true


> All of this would be fine. What makes your example confusing is that you use 
> `println` to output them and see that they "have the same value".

Not really. I use println to not let them escape (which would change results, 
obviously) and only print out the pointer values to show that we can construct 
some piece of code that sees them as identical, see above.

> Note that if you *don't* convert an `unsafe.Pointer` to `uintptr`, you have 
> no way to argue that they "are actually equal"

I can by doing something like

        *aa = 42
        fmt.Println(aa == ba, *ba)

“Two pointer values are equal if they point to the same variable” - aa and ba 
do. Note that “A variable is a storage location for holding a value.”

>> I’m advocating for at least a FAQ article,
> 
> I tend to agree, though I'm not sure how to phrase that, beyond saying "do 
> not make any assumptions about the identity pointers to zero-sized variables 
> or with zero-sized base types or that where derived from one of those" and 
> I'm not sure how helpful that is.

It seems like a frequently asked question to me ;)

>> but also think the specification should be adapted, for clarity but also for 
>> the fact that only one pointer pointing to a zero-sized variable can compare 
>> differently to anything over time, even things having the same address value.
> 
> Note that "address value" is not something that exists within the spec. As 
> for clarifying the spec here, maybe. I do think the behavior is covered, as I 
> outlined above. And as above, I'm not sure how to clarify it further, while 
> still leaving up the space we want to left open.

I vote for making this openness explicit, meaning that even the optimizer is 
free to make assumptions that do not hold during runtime. So if you have a 
pointer derived from something pointing to a zero-size type it can compare with 
different results over time, even false when having the same value. I do not 
believe that is what’s currently in the spec.

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/AEB06A98-1372-4478-BBEB-514B617852A2%40fillmore-labs.com.

Reply via email to