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

feature: support for tag 55799 self-describing CBOR #227

Closed
philandstuff opened this issue May 7, 2020 · 4 comments
Closed

feature: support for tag 55799 self-describing CBOR #227

philandstuff opened this issue May 7, 2020 · 4 comments
Milestone

Comments

@philandstuff
Copy link

CBOR defines a self-describing tag which can be added to any item in a CBOR stream. It has no semantic meaning on the content:

It does not impart any
special semantics on the data item that follows; that is, the
semantics of a data item tagged with tag 55799 is exactly identical
to the semantics of the data item itself.

I therefore want to be able to decode some CBOR, but silently strip all 55799 tags as I encounter them.

TagSet.Add(TagOptions, reflect.Type, int) seems like the right place to try to do this, except that a) I don't want to add 55799 tags when I encode, and b) I want to be able to strip a 55799 tag in any location, on any item encoding any type. But this method only lets me register a tag for a specific named type, not for all types.

Is it possible to a) achieve this using existing fxamacker/cbor features? or b) allow fxamacker/cbor to (optionally) silently strip all 55799 tags when decoding?

(For context, my use case is implementing a Dhall library; it has defined CBOR semantics here, including the possibility of tag 55799 appearing anywhere.)

(See also this similar issue in another library: ugorji/go#300)

@fxamacker
Copy link
Owner

@philandstuff thanks for opening this issue!

Is it possible to a) achieve this using existing fxamacker/cbor features?

Yes. And I'm also going to make it automatic in the next release.

I don't want to add 55799 tags when I encode
...
I want to be able to strip a 55799 tag in any location, on any item encoding any type. But this method only lets me register a tag for a specific named type, not for all types.

There's no need to register tags to handle 55799.

BTW, this library can use separate tag registrations (different TagSet) for encoding and decoding.

Details

There are two CBOR decoding scenarios for tag 55799:
A. ✔️ decode to user-specified Go type
B. ℹ️ decode to empty interface (interface{})

"A" already ignores tag 55799 for you because unrecognized tag numbers are ignored and the tag content is decoded to the user-specified Go type.

"B" currently decodes each unrecognized tag item to a cbor.Tag struct, which contains tag number and tag content. For now, you can manually discard the tag number and keep the tag content from cbor.Tag.

type Tag struct {
	Number  uint64
	Content interface{}
}

I'm going to open a bug report to ignore tag 55799 when decoding to empty struct. Once that bug is fixed, "B" should handle 55799 automatically for you with no extra step required.

Please let me know if this works for you.

@philandstuff
Copy link
Author

Yes that would work great for me 👍

@fxamacker
Copy link
Owner

@philandstuff commit 28e39be handles tag number 55799 by skipping it when it is a prefix.

https://play.golang.com/p/Fd0IbCQO_bL

Although this isn't an official release, commit 28e39be has passed fuzzing since yesterday (220 million execs and counting).

Please let me know if there is a problem.

@philandstuff
Copy link
Author

works a treat! 👍

philandstuff added a commit to philandstuff/dhall-golang that referenced this issue May 12, 2020
Upstream has added support in master for tag 55799:
fxamacker/cbor#227
philandstuff added a commit to philandstuff/dhall-golang that referenced this issue May 12, 2020
Upstream has added support in master for tag 55799:
fxamacker/cbor#227
@fxamacker fxamacker added this to the v2.3.0 milestone May 30, 2021
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

No branches or pull requests

2 participants