jsoncpp-devel Mailing List for json-cpp

On Tue, May 24, 2011 at 7:34 AM, Aaron Jacobs <ja...@go...> wrote:
> 2^64 - 1 -> isDouble

Sorry, this should be:

2^64 - 1 -> isUInt64, isDouble

On Mon, May 23, 2011 at 9:50 PM, Baptiste Lepilleur
<bap...@gm...> wrote:
> If I understood your problem correctly, this should solve your backward
> compatibility issue. Is that correct?

Almost but not quite, I think. Now the numbers in [2^32, 2^64) will be
parsed as uint64s, and the code above will always return kError
because both isUInt and isDouble return false, even though it used to
work for those values. I think maybe the only choice here is to have
each of the isFoo methods return true iff asFoo will work, whether
that's the best way to represent the number or not. For example:

0.7 -> isDouble
1 -> isUInt, isInt, isUInt64, isInt64, isDouble
2^32 -> isUInt, isUInt64, isDouble
2^40 -> isUInt64, isDouble
2^64 - 1 -> isDouble
2^64 -> isDouble

I can imagine that this change would cause problems for other existing
code, but I'm not sure. What do you think?

Perhaps the best way would have been to have users explicitly opt in
for 64-bit support. That is, add an option to the constructor of
Json::Reader that defaults to false, and if you set it to true then
you're asserting that your code doesn't suffer from the problem
mentioned above. I guess it's too late for that, though.

2011/5/23 Aaron Jacobs <ja...@go...>

> Hi Baptiste and jsoncpp-devel,
>
> I'm a software engineer at Google, where we use jsoncpp for a few projects.
> We've made a number of modifications internally, and I'd like to contribute
> them back to the public repository.
>
>
Thanks for contributing this back.

Below are some general comments concerning the individual patches.


> Here are a few patches that are ready to apply to SVN revision 192:
>
>    https://github.com/jacobsa/jsoncpp/commit/d7377e3c438490

=> OK

To make sure I understand the issue: sscanf on Mac OS X will write in the
format string provided as parameter even though it is declared const char *?

    https://github.com/jacobsa/jsoncpp/commit/7d2314b1fef8f7
=> OK

   https://github.com/jacobsa/jsoncpp/commit/1de4ede76d27b0

=> I see a few problems with this patch:
- JSON_FAIL_MESSAGE is bugged if there is no exception (e.g.
multi-statements). IMHO it should just call a function that dump message and
then call abort().
- partial duplication of assertions macros already present in json_value.cpp

I think we should move the assertion/failure macros from json_value.cpp  to
a common private header instead of duplicating them.

In the future, we may want to provide hook to allow user to customize what
happens on failure (e.g. like google breakpad integration or whatever stack
capture tool you happen to use...)

   https://github.com/jacobsa/jsoncpp/commit/8945bfb0a29235

=> OK

What's the easiest way to get these committed to the main jsoncpp SVN repo?
> I've got several more changes to contribute back, but wanted to get the
> ball
> rolling with these first.
>

I'll contact you privately.

Thanks for your time,
Baptiste.


> Thanks,
> Aaron Jacobs
>

On Mon, May 23, 2011 at 1:50 PM, Baptiste Lepilleur <
bap...@gm...> wrote:

> I propose making the following changes:
> 1) isUInt() returns true only asUInt() can succeed. Similar changes for
> isInt().
>     I think this contract should be generalized. e.g. asUInt() should
> succeed if the value is a positive signed int Value.
> 2) Adds new member functions:
>    isUInt64() that returns true only if asUInt64() can succeed.
>    and isInt64()...
>
> If I understood your problem correctly, this should solve your backward
> compatibility issue. Is that correct?
>

My proposal would be to remove the int/uint distinction entirely, since
JavaScript and JSON do not distinguish between the two. In my own JSON code
i simply use int64_t for all integers and double for doubles (though JS
there's just a single Number type, if i'm not mistaken). In my own use of
json libs and JS engines (SpiderMonkey, QtScript, and Google v8), i've
always found the distinction between signed/unsigned to be philosophically
unsettling because JS doesn't natively have unsigned numbers.

JSON, in fact, does not specify the precision of numeric values (
http://www.ietf.org/rfc/rfc4627.txt?number=4627), probably because it would
be impossible to guaranty that any given implementation (in umpteen[1]
different programming languages) can honor that, e.g. a certain embedded
environment might not have integers >32 bits. Section 2.4 of the JSON RFC
notably does not specify any limits on numbers, so 2^75 (when written in
expanded integer form) is syntactically legal, according to the grammar, but
is almost certainly semantically illegal in any modern computer.

These pages:

http://www.hunlock.com/blogs/The_Complete_Javascript_Number_Reference
http://www.jibbering.com/faq/#FAQ4_7

say that in JS integers are reliable up to "15-16" digits (53 bits). Thus
int64_t can legally hold any JS-legal value.

Obviously, JSON is _not_ only for JavaScript, but i'm using JS as the
baseline here because (A) JSON derives from JS and (B) it is primarily
consumed by JS applications (though it is primarily generated by other
technologies).


[1] = American slang for "very many"

-- 
----- stephan beal
http://wanderinghorse.net/home/stephan/

I think you put your finger on something missing in the API.

I propose making the following changes:
1) isUInt() returns true only asUInt() can succeed. Similar changes for
isInt().
    I think this contract should be generalized. e.g. asUInt() should
succeed if the value is a positive signed int Value.
2) Adds new member functions:
   isUInt64() that returns true only if asUInt64() can succeed.
   and isInt64()...

If I understood your problem correctly, this should solve your backward
compatibility issue. Is that correct?

What do you think of this proposal?

Baptiste.

2011/5/23 Aaron Jacobs <ja...@go...>

> Hi all,
>
> I'm working on updating Google's internal version of jsoncpp from an
> ancient
> commit to the most recent version (SVN rev 192), but having some trouble. I
> think I've run into a backwards incompatible change that makes it nearly
> impossible for us to upgrade.
>
> In particular, there's jsoncpp-using code that looks something like this:
>
>    Json::Value value = ...
>    unsigned int value =
>        value.isUInt() ? value.asUInt() :
>            (value.isDouble() ? value.asDouble() : kError);
>
> That is, the code uses the isFoo methods to decide which asFoo method to
> call.
> The problem is that at SVN rev 192, values parsed as integers greater than
> 2^32 will return true for isUInt(), but have an assertion failure for
> asUInt():
>
>    value_.uint_ <= maxUInt
>    "unsigned integer out of UInt range"
>
> You can see this by parsing the string "31121983701778432", for example.
>
> As far as I can tell, there's no way for me to update to the latest version
> of
> jsoncpp without either changing the code above or breaking it (introducing
> incorrectness or a crasher bug into production). Updating the code is not
> an
> option for me since there is too much of it.
>
> Do you have any advice? In particular, am I missing something in the
> Json::Value API?
>
> Thanks,
> Aaron
>

Hi all,

I'm working on updating Google's internal version of jsoncpp from an ancient
commit to the most recent version (SVN rev 192), but having some trouble. I
think I've run into a backwards incompatible change that makes it nearly
impossible for us to upgrade.

In particular, there's jsoncpp-using code that looks something like this:

    Json::Value value = ...
    unsigned int value =
        value.isUInt() ? value.asUInt() :
            (value.isDouble() ? value.asDouble() : kError);

That is, the code uses the isFoo methods to decide which asFoo method to call.
The problem is that at SVN rev 192, values parsed as integers greater than
2^32 will return true for isUInt(), but have an assertion failure for
asUInt():

    value_.uint_ <= maxUInt
    "unsigned integer out of UInt range"

You can see this by parsing the string "31121983701778432", for example.

As far as I can tell, there's no way for me to update to the latest version of
jsoncpp without either changing the code above or breaking it (introducing
incorrectness or a crasher bug into production). Updating the code is not an
option for me since there is too much of it.

Do you have any advice? In particular, am I missing something in the
Json::Value API?

Thanks,
Aaron