[Info-vax] openvms and xterm

[Arne Vajhøj]

On 4/24/2024 8:36 PM, Dan Cross wrote:
> In article <v0c6t7$2jtvn$1 at dont-email.me>,
> Arne Vajhøj  <arne at vajhoej.dk> wrote:
>> 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.

Trying to stuff 100000000000000001 into a 32 bit integer
or a 64 bit floating point create a problem.

But it does not matter if the format is JSON or XML or YAML
or whatever.

The developer made a design error. And the language/library
did not object.

But none of that is a problem in the format. The JSON has the
correct value.

>> [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.

You must have missed this part:

# The fact that it ultimately is the developers responsibility
# to select proper data types does not mean that programming languages
# and JSON libraries can not help catch errors.
#
# If it is obvious that an unexpected/useless result is being
# produced then it should be flagged (return error code or throw
# exception depending on technology).
#
# Let us go back to the example with 100000000000000001.
#
# Trying to stuff that into a 32 bit integer by like parsing
# it as a 64 bit integer and returning the lower 32 bits
# is in my best opinion an error. Nobody wants to get an int
# with 1569325057 from retrieving a 32 bit integer integer
# from "100000000000000001". It should give an error.
#
# The case with a 64 bit floating point is more tricky. One
# could argue that 100000000000000001.0 is the expected
# result and that 100000000000000000.0 should be considered
# an error. And it probably would be an error in the majority
# of cases. But there is actually the possibility that
# someone that understand floating point are reading JSON
# and expect what is happening and does not care because
# there are some uncertainty in the underlying data. And
# creating a false error for people that understand FP data
# types to prevent those that do not understand FP data types
# from shooting themself in the foot is not good.

Arne