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

Make Decode canonicalize CBOR. #17

Merged
merged 5 commits into from Jul 3, 2017
Merged

Conversation

Stebalien
Copy link
Member

@Stebalien Stebalien commented Jun 30, 2017

Also:

  • Actually use pre-computed CIDs (trivial bug fix).
  • Cleanup DecodeInto and make it possible to DecodeInto non-objects. This came up when refactoring the decoding logic.
  • gx import go-block-format because I apparently forgot to do this.
  • gx release 1.2.4 so we can use this in ipfs/go-ipfs/#4023

I've also imported a variant of the canonicalization test so I don't re-introduce this bug in the future...

if !nd2.Cid().Equals(nd1.Cid()) || !bytes.Equal(nd2.RawData(), nd1.RawData()) {
t.Fatal("re-decoding a canonical node should be idempotent")
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If test_objects/non-canon.cbor is taken from go-ipfs I'd add a check for whether CID is zdpuAmxF8q6iTUtkB3xtEYzmc5Sw762qwQJftt5iW8NTWLtjC here

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

node.go Outdated
@@ -77,6 +63,19 @@ func DecodeInto(b []byte, v interface{}) error {

}

// Decode's a cbor node into an object.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Decodes

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚶‍♂️ 🎶

Copy link
Member

@whyrusleeping whyrusleeping left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM after @magik6k's comments are addressed

@coveralls
Copy link

Coverage Status

Coverage increased (+2.9%) to 66.15% when pulling c348930 on Stebalien:fix/16 into ec62d7b on ipfs:master.

1 similar comment
@coveralls
Copy link

Coverage Status

Coverage increased (+2.9%) to 66.15% when pulling c348930 on Stebalien:fix/16 into ec62d7b on ipfs:master.

@coveralls
Copy link

coveralls commented Jun 30, 2017

Coverage Status

Coverage increased (+2.9%) to 66.15% when pulling 774d79a on Stebalien:fix/16 into ec62d7b on ipfs:master.

@coveralls
Copy link

Coverage Status

Coverage increased (+2.9%) to 66.15% when pulling cdd418e on Stebalien:fix/16 into ec62d7b on ipfs:master.

1 similar comment
@coveralls
Copy link

Coverage Status

Coverage increased (+2.9%) to 66.15% when pulling cdd418e on Stebalien:fix/16 into ec62d7b on ipfs:master.

@Stebalien
Copy link
Member Author

@whyrusleeping it should all be fixed (I've also added a bit of documentation to the Decode/DecodeBlock functions).

In the future, do you prefer keeping history intact while a PR is under review?

@magik6k
Copy link
Member

magik6k commented Jul 1, 2017

Updated ipfs/kubo#4023 with current gx version of this to see if tests pass

@whyrusleeping whyrusleeping merged commit c6553d8 into ipfs:master Jul 3, 2017
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.

None yet

4 participants