[OPEN-ILS-DEV] PATCH: osrf_json_utils.h (scientific notation)

[Scott McKellar]

This tiny patch enables the JSON parser to accept a capital 'E' as
well as a lower case 'e' in a number expressed in scientific notation.

If there is some reason to insist on lower case -- which I doubt --
then disregard this patch.

-----------

As long as we're on the subject of numeric representations, I'm 
going to raise an issue that has been bothering me for a while.

When we parse a number within a JSON string, we immediately convert it
into a double and store it as such within the jsonObject.  Due to the
inherent imprecision of floating point, this conversion may change
the numeric value.

For example, suppose the JSON string consists of:

    {"Avogadro" : 6.023e23 }

If I parse it and then convert it back to text, I get:

    {"Avogadro":602299999999999975882752.000000}

Likewise a 19-digit Visa card number 4823396004872278801 turns into
4823396004872279040.000000 -- a disaster for financial transactions.
Dewey decimal numbers will likewise get mangled.

Granted, credit card numbers and Dewey decimals should be encoded
as character strings in the JSON text, not as numbers.  If we need
to do any arithmetic on a legitimately numeric value, we can't avoid
risking some loss of precision.

Nevertheless, there may be cases where an application needs merely
to reproduce a numeric value without doing any arithmetic on it.  
For example, we might want to filter the JSON text so as to remove 
certain parts of it, leaving the rest intact.  In such a case we
would want to preserve the original content unchanged.

Accordingly, I propose that numeric values be stored as character
strings, in order to preserve the original values exactly.  In a
context where we don't need to do any arithmetic on it, we can
extract it in the original format.  Only when necessary would we
convert it to a numeric value.  This way we would avoid losing
information when we don't have to.

The object type would still be JSON_NUMBER, but the internal
representation would be different.

The strategy would be:

1. Identify all locations that access the value.n member of a
jsonObject.

2. Rewrite them to call either jsonObjectToSimpleString() or
jsonObjectGetNumber(), according to circumstance.

3. Modify osrf_json_object.c as needed to store the number as a
character string.

4. Eliminate the value.n member altogether.  If we overlooked any
spots that used it, we'll find them in the next build.

Admitted drawbacks:

1. Storing numbers as character strings would require us to allocate
and free buffers, incurring additional overhead.

2. We may not want to take these measures until the legacy JSON
code is gone, so that we wouldn't have to change things in both
places.

Scott McKellar
http://home.swbell.net/mck9/ct/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osrf_json_utils_h_2.patch
Type: text/x-patch
Size: 549 bytes
Desc: 3131002281-osrf_json_utils_h_2.patch
Url : http://list.georgialibraries.org/pipermail/open-ils-dev/attachments/20071211/028ee84a/osrf_json_utils_h_2.bin