cbor
cbor copied to clipboard
Create optional byte string wrapper for map keys
Description (motivation)
This allows the parsing of CBOR data containing maps with byte string keys, which is commonly seen in Cardano blockchain data. The default behavior remains the legacy behavior (throw an error) for backward compatibility.
This is related to #312
PR Was Proposed and Welcomed in Currently Open Issue
This PR was proposed and welcomed by maintainer(s) in issue #
Closes #
NOTE: I'm leaving this section blank, since this fix was not necessarily "welcomed" by the maintainer :)
Checklist (for code PR only, ignore for docs PR)
- [x] Include unit tests that cover the new code
- [x] Pass all unit tests
- [x] Pass all 18 ci linters (golint, gosec, staticcheck, etc.)
- [x] Sign each commit with your real name and email.
Last line of each commit message should be in this format:
Signed-off-by: Firstname Lastname [email protected] - [x] Certify the Developer's Certificate of Origin 1.1 (see next section).
Certify the Developer's Certificate of Origin 1.1
- [x] By marking this item as completed, I certify the Developer Certificate of Origin 1.1.
Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
660 York Street, Suite 102,
San Francisco, CA 94110 USA
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
@fxamacker Any chance you could review this PR/allow tests to run? This functionality would be really useful.
@jwitko My current schedule is swamped, so I allowed the tests to run without review.
@jwitko My current schedule is swamped, so I allowed the tests to run without review.
Thank you!
Until this is reviewed, tested for performance regressions, and fuzzed, maybe we can create a branch in this repo that includes this PR until we can merge into main branch.
@fxamacker and others, what do you think of this idea?
Until this is reviewed, tested for performance regressions, and fuzzed, maybe we can create a branch in this repo that includes this PR until we can merge into main branch.
@fxamacker and others, what do you think of this idea?
For what purpose? This PR's branch can already be checked out using the pull/319/head
ref (assuming you've explicitly fetched it)
https://github.com/fxamacker/cbor/issues/320 will handle this use case, just like that "encoding/json" doing.
func main() {
obj := map[string]interface{}{string([]byte{0, 1, 2, 3}): "hello"}
data, err := json.Marshal(obj)
fmt.Println(err, string(data))
var x interface{}
err = json.Unmarshal(data, &x)
fmt.Println(err, x)
if m, ok := x.(map[string]interface{}); ok {
for k, v := range m {
fmt.Println(len(k), k, v)
}
}
}
#320 will handle this use case, just like that "encoding/json" doing.
I'm not entirely sure that this is the same case, since you're converting the byte array map key to a string. The original CBOR contains a map with bytestring/array keys (which is different than text strings), and I see nothing in #342 that will change the way this is handled.
Since it doesn't seem like this change is wanted and there are now conflicts, I'm just going to close this PR.
I implemented a wrapper object that can use the ByteString
type from this PR when parsing arbitrary CBOR in order to solve my problem. This can be seen in https://github.com/cloudstruct/go-cardano-ledger/pull/16
@agaffney I'm sorry about the delayed response. It has been a hectic year and I have some time off at end of year planned to try to take care of pending PRs and other delayed tasks.
@fxamacker Is there still a chance of getting something like this merged? It would be a lot more convenient if I didn't have to use a wrapper object, since it adds a layer of indirection when accessing the parsed value, as well as it not supporting deserializing into an arbitrary struct nested under the top-layer value using the wrapper.
@agaffney I'll have a better idea after I take a closer look at this PR and https://github.com/cloudstruct/go-cardano-ledger/pull/16 during end-of-year holidays.
My job consumed most of my weekends this year, so I'll be catching up on delayed tasks like this during the holidays.
Hey @agaffney I finished reviewing this PR and have a local copy with changes that I've tested and am fuzzing.
p.s. my father was hospitalized and is going into surgery this week so there may be delays in communications.
Take care of your personal stuff and don't feel compelled to look at this. I'm not blocked on this, but I'll gladly remove my workaround in favor of this (or similar) upstream support if/when it gets merged.
@agaffney Thanks. It looks like it would be easier for me to open a new PR, mark you as co-author, and merge that one after fuzzing it.
Would that be OK with you if I open a new PR and add you as its co-author?
Yes, that's fine with me.
Closing this because PR #376 includes this PR and some changes, with permission from @agaffney.