Skip to content
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

Avoid relying on undefined behavior in assert.ObjectsAreEqual(). #94

Merged
merged 1 commit into from
Nov 24, 2014

Conversation

neilconway
Copy link
Contributor

The previous assert.ObjectsAreEqual() implementation is broken in go 1.4beta1:

x := uint64(3)
log.Printf("equal? %t", assert.ObjectsAreEqual(3, x))

This prints "true" under Go 1.3 and "false" under 1.4beta1 (amd64/darwin).

The reason is that the ObjectsAreEqual() was comparing two reflect.Value values
for equality using ==, but the behavior of that operation is apparently
undefined (https://code.google.com/p/go/issues/detail?id=9034). The fix is to do
the type conversion and then do the comparison between two interface{} values.

The previous assert.ObjectsAreEqual() implementation is broken in go 1.4beta1:

   x := uint64(3)
   log.Printf("equal? %t", assert.ObjectsAreEqual(3, x))

This prints "true" under Go 1.3 and "false" under 1.4beta1 (amd64/darwin).

The reason is that the ObjectsAreEqual() was comparing two reflect.Value values
for equality using ==, but the behavior of that operation is apparently
undefined (https://code.google.com/p/go/issues/detail?id=9034). The fix is to do
the type conversion and then do the comparison between two interface{} values.
@neilconway
Copy link
Contributor Author

Ping? This issue makes testify unusable with Go 1.4 for me, unfortunately.

@tylerstillwater
Copy link
Contributor

LGTM. Thank you! We'll get this merged asap.

@neilconway
Copy link
Contributor Author

Ping?

matryer pushed a commit that referenced this pull request Nov 24, 2014
Avoid relying on undefined behavior in assert.ObjectsAreEqual().
@matryer matryer merged commit faedd6e into stretchr:master Nov 24, 2014
@matryer
Copy link
Member

matryer commented Nov 24, 2014

pong

neilconway pushed a commit to neilconway/testify that referenced this pull request Nov 25, 2014
The change in stretchr#94 resulted in using == to compare two values that might not be
comparable. Hence, this resulted in a panic for situations like:

    ObjectsAreEqual(map[int]int{5: 10}, map[int]int{10: 20})

The fix is to use reflect.DeepEqual() instead.
@willfaught
Copy link
Contributor

This change breaks causes panics when comparing slices or structs containing slices.

@neilconway
Copy link
Contributor Author

Yes, see fix in #103

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants