[Info-vax] openvms and xterm

[Dan Cross]

In article <v0c6t7$2jtvn$1 at dont-email.me>,
Arne Vajhøj  <arne at vajhoej.dk> wrote:
>On 4/23/2024 9:03 AM, Dan Cross wrote:
>> 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.
>
>This will be a relative long post. Sorry.
>
>The problem at hand has nothing to do with JSON. It is
>a string to numeric and data types problem.

It is a problem with a format that permits silently lossy
conversions.

>[snip]
>But selecting an appropriate data type for a given piece
>of data based on its possible values and usage is
>core responsibility for a developer.

One hopes one also has tools that permit detection of
truncation.  You also ignored the point about how third-party
tools for manipulating JSON will silently lose data.

	- Dan C.