Closed breese closed 10 years ago
As a malformed data. The reason to have there signed integers is to make library logic more clear since you don't have to support same integer markers that needs to be parsed in different ways depending on their context.
How are UBJSON parsers expected to react to malformed data? Bail out? ("writer makes right")
@breese , I couldn't say for other libs, but for Python I raise assertion error in such case. However, it should be changed for some more solid ValueError
based solution.
@kxepal My previous question was a bit vague.
I am really asking if the UBJSON spec has (or ought to have) requirements for how to handle malformed data.
For instance, XML processors are requires to report errors and cease processing (this is the "writer makes right" policy). See http://en.wikipedia.org/wiki/Well-formed_document
@breese , oh, sorry for misunderstood. CC @thebuzzmedia then - it's a good question (:
@breese Yes, the spec should absolutely clarify how to handle error conditions like this. There are oversights where I forget to clarify this (like you pointed out).
Thank you. I'll leave this open as a reminder.
.net implementation will throw one of system exceptions. so, it's implementation specific, because, for example c/c++ compilers, can have undefined behaviour. In .net lib we have two ways: 1 - exception will thrown, 2 - use safe wrappers (try-... methods). Each system have own way to solve cases with malformed data. If spec will provide a useful way - it's will be implemented.
But anyway undefined behaviour it is normal.
Fixed - http://ubjson.org/developer-resources/#library_req
I don't love where this is at the moment (that page is a bit sloppy) but I'll move it around as I find a better place for it.
Now that the length (e.g. for strings) has changed from an unsigned to a signed integer, how is a negative length to be handled?
PS: We ought to specify that the signed integers are encoded in two's complement. See http://en.wikipedia.org/wiki/Signed_number_representation