On Thu, Jun 20, 2013 at 4:58 PM, Jan Nijtmans <jan.nijtm...@gmail.com>wrote:
> Fossil does it's own printf-like formatting, so whatever solution chosen > can be implemented consistantly. size_t is the simplest, with least > impact on 32-bit systems. Making everything i64 is possible too, > but Richard already remarked on that: > > Are you sure it is worth it? > i'm ambivalent, more or less. i've considered the 64-bit problem for the JSON bits but marked it as yellow in the JSON docs, meaning "deal with it when/if it becomes a problem." > >Careful - JSON itself does NOT specify integer precision, which means > that just because fossil can now generate e.g. > > the value 1<<40, doesn't mean that any given consumer on the other end > can read it properly (or even fail > > I thought that javascript uses 64-bit floating-point for numbers > internally, which means that integers up to 1<<53 > should be no problem for any compliant implementation. That's a lot > more than 1<<32. ! > If memory serves me correct, yes, JS specifies 53 bits of precision (but it doesn't really differentiate between doubles and integers). But JSON != JS (it just syntactically derives from it). In fact, one of the first points the IETF threads undertook was to rename the format to (IIRC) The JSON Data Interchange Format, and removing the acronym meaning of JSON altogether (in the hopes of avoid JSON==JS confusion). JSON is a format which can (and is) implemented in such esoteric environments as Oracle PLSQL and some language called Rebol (no idea...). So JSON as a format cannot specify/require a given lower limit on numeric precision. A limit of 8 bits is just as legal, from JSON's perspective, as a limit of 83. But i'm just being technically pedantic, so don't take all that too seriously. i see nothing wrong with using sqlite3_int64 everywhere, to be honest, and wouldn't mind adding a patch to the upstream JSON bits which use sqlite3_int64 when compiling for fossil (they already have one such place so that they use fossil_alloc() and fossil_free(), to inherit its die-on-alloc-failure behaviour, which reduces (greatly) the amount of error checking in the fossil JSON bits). -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
