Re: [Jsoncpp-devel] Backwards incompatible change in jsoncpp 64-bit support

[Stephan B. <sg...@go...>]

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/