[Info-vax] openvms and xterm

[Dan Cross]

In article <v088m8$1juj9$1 at dont-email.me>,
Simon Clubley  <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2024-04-22, Dan Cross <cross at spitfire.i.gajendra.net> wrote:
>>
>> Eh, JSON has its own problems; since the representation of
>> numbers is specified to be compatible with floats, it's possible
>> to lose data by translating it through JSON (I've seen people
>> put e.g. machine addresses in JSON and then be surprised when
>> the low bits disappear: floating point representations are not
>> exact over the range of 64-bit integers!).
>
>I would consider that to be strictly a programmer error. That's the
>kind of thing that should be stored as a string value unless you are
>using a JSON library that preserves integer values unless decimal data
>is present in the input data (and hence silently converts it to a float).
>
>I don't expect people to write their own JSON library (although I hope
>they can given how relatively simple JSON is to parse), but I do expect
>them to know what values they can use in libraries in general without
>experiencing data loss.

In modern languages, one can often derive JSON serialization and
deserialization methods from the source data type, transparent
to the programmer.  Those may decide to use the JSON numeric
type for numeric data; this has surprised a few people I know
(who are extraordinarily competent programmers).  Sure, the fix
is generally easy (there's often a way to annotate a datum to
say "serialize this as a string"), but that doesn't mean that
even very senior people don't get caught out at times.

But the problem is even more insideous than that; popular tools
like `jq` can take properly serialized source data and silently
make lossy conversions.  So you might have properly written,
value preserving libraries at both ends and still suffer loss
due to some intermediate tool.

JSON is dangerous.  Caveat emptor.

	- Dan C.