-
Notifications
You must be signed in to change notification settings - Fork 22
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
This shouldn't encode JS undefined
as CBOR "undefined".
#36
Comments
So the options to deal with this would be either to not allow it (which would be OK but inconvenient), or do what JSON.stringify does: An undefined value in a map is serialised as if the corresponding key is not present at all. An undefined value in an array is converted to
|
Sounds reasonable to me. |
I'm in favour of not allowing |
I think failing on discovering The above example from |
As this is a library used in the context of JavaScript where The way the JSON serializer handles this for objects will result in a similar object after parsing. Consider this:
For the array case, I also agree with the JSON decision, as it gets as close as possible to the original and probably causes very few side effects. I think that except where there are very compelling reasons, borc should align with the conventions used by other serializers, such as JSON. Additionally, I think there are many use cases where borc is going to be processing arbitrary data that may only contain For those reasons, I believe that the |
I really don't know what is best here. The principled thing to do would be to reject undefined since it is not representable in cbor, so a js -> cbor -> js transformation will not yield an identical object. Same for things like functions. But on the other hand in the javascript ecosystem people tend to assume that libraries will just work best effort with whatever they are given. E.g. JSON.stringify just ignores stuff that it can not serialise, such as functions, instead of failing. What is the current behaviour when trying to serialise a function? Whatever the policy is, it should be consistent. |
Currently if you try to serialise a function an error is thrown. Here's an example: const cbor = require('borc')
const myfun = () => {}
toEncode = {myfun: myfun}
console.log(JSON.stringify(toEncode))
console.log(cbor.encode(toEncode)) The output is: $ node testfun.js
{}
/home/vmx/src/pl/misc/cborencoding/node_modules/borc/src/encoder.js:430
throw new Error('Unknown type: ' + typeof obj + ', ' + (obj ? obj.toString() : ''))
^
Error: Unknown type: function, () => {}
at Encoder.pushAny (/home/vmx/src/pl/misc/cborencoding/node_modules/borc/src/encoder.js:430:15)
at Encoder._pushRawMap (/home/vmx/src/pl/misc/cborencoding/node_modules/borc/src/encoder.js:367:17)
at Encoder._pushObject (/home/vmx/src/pl/misc/cborencoding/node_modules/borc/src/encoder.js:344:17)
at Encoder.pushAny (/home/vmx/src/pl/misc/cborencoding/node_modules/borc/src/encoder.js:402:21)
at Object.encode (/home/vmx/src/pl/misc/cborencoding/node_modules/borc/src/encoder.js:507:21)
at Object.<anonymous> (/home/vmx/src/pl/misc/cborencoding/testfun.js:7:18)
at Module._compile (internal/modules/cjs/loader.js:702:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:713:10)
at Module.load (internal/modules/cjs/loader.js:612:32)
at tryModuleLoad (internal/modules/cjs/loader.js:551:12) |
Then it seems only consistent to also throw an error on |
See: https://tools.ietf.org/html/rfc7049#section-3.8
CBOR undefined means the encoding is undefined. Now, technically, the encoding for
undefined
is undefined (unless you want to define it to be null) butundefined
really shouldn't exist in "good" CBOR objects.The text was updated successfully, but these errors were encountered: