Skip to content

reflect: should DeepEqual handle cyclic references? #15610

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
gavv opened this issue May 9, 2016 · 5 comments
Closed

reflect: should DeepEqual handle cyclic references? #15610

gavv opened this issue May 9, 2016 · 5 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@gavv
Copy link

gavv commented May 9, 2016

Hi!

Here is a test case:

package main

import "reflect"

type Test *Test

func makeTest() Test {
    var t1, t2 Test
    t1 = new(Test)
    t2 = &t1
    *t1 = &t2
    return t1
}

func main() {
    a := makeTest()
    b := makeTest()

    reflect.DeepEqual(a, b)
}

I'm using go 1.6.1 on Linux and this test fails with a stack overflow.

It seems that reflect.DeepEqual could theoretically handle cyclic references, but it doesn't check visited map for pointers.

Is this a bug (probably regression) of feature? If it's a feature, it will be nice if it would be documented.

@bradfitz bradfitz changed the title Should reflect.DeepEqual handle cyclic references? reflect: should DeepEqual handle cyclic references? May 9, 2016
@bradfitz bradfitz added this to the Go1.8Maybe milestone May 9, 2016
@bradfitz
Copy link
Contributor

bradfitz commented May 9, 2016

I suspect we're done making changes to DeepEqual, but I'll keep this bug open for us to decide later, during the Go 1.8 dev cycle.

@mdempsky
Copy link
Contributor

mdempsky commented May 9, 2016

This seems like a legit, albeit niche, inconsistency to me. If Test's declaration is changed from type Test *Test to type Test struct { p *Test } or type Test [1]*Test and makeTest is updated accordingly, then DeepEqual returns immediately. There's nothing in DeepEqual's godocs to suggest this inconsistency is / should be present.

The obvious fix is to simply relax the deepEqualValue's "hard" predicate to include Ptr-Kinded Values. Downside is this would probably grow the number of entries needed in the visited map for typical programs that don't create cycles using only pointer types.

I suspect we can fix it somehow without regressing typical programs though.

@gavv How did you discover this problem? Do you have a real-world application that's negatively affected by it?

@gavv
Copy link
Author

gavv commented May 9, 2016

The obvious fix is to simply relax the deepEqualValue's "hard" predicate to include Ptr-Kinded Values.

Yes, this does work, just checked.

How did you discover this problem? Do you have a real-world application that's negatively affected by it?

It was a failing test for deepcopy module found on github. Not a real-world application though, but I assume this test worked before so it's probably a regression.

@rsc
Copy link
Contributor

rsc commented Sep 30, 2016

Yes, this is a bug, since type Test struct { X *Test } works fine. It's a bug that's been there since the initial Go release, but still a bug.

Another failing case:

package main

import "reflect"

type Test interface{}

func makeTest() Test {
    var t1, t2 Test
    t1 = new(Test)
    t2 = &t1
    *t1.(*Test) = &t2
    return t1
}

func main() {
    a := makeTest()
    b := makeTest()
    reflect.DeepEqual(a, b)
}

In the implementation, the goal of the 'hard' predicate is to avoid making visited too big. I think it should work to change hard to be

hard := func(t Type) bool {
    switch t.Kind() {
    case Array, Map, Slice, Struct:
        return true
    case Ptr:
        t = t.Elem()
        return t.Kind() == Ptr || t.Kind() == Interface
    }
    return false
}

@rsc rsc added the NeedsFix The path to resolution is known, but the work has not been done. label Sep 30, 2016
@gopherbot
Copy link
Contributor

CL https://golang.org/cl/31588 mentions this issue.

@golang golang locked and limited conversation to collaborators Oct 24, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

5 participants