[Info-vax] openvms and xterm

[Dan Cross]

In article <v0c98k$2kbf5$1 at dont-email.me>,
Arne Vajhøj  <arne at vajhoej.dk> wrote:
>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.

Obvious.

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

That's not the problem, though.

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

No, it often doesn't.  Because there are numeric constants that
are not representable at all in the most common encoding used
by JSON _tools_.

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

That's obvious.  What you don't seem to understand is that there
are very common tools outside of the programmer's control that
are used to manipulate JSON data that perform silently lossy
conversions.  That is, those tools not only don't "help catch
errors", they actually introduce them.

	- Dan C.