dcm2json: silently ignore -N, --encode-as-number for values outside the range [-(2^53)+1, (2^53)-1]

[malaterre]

Describe the bug

dcm2json remains extremely vague about CP-1861 a warning (or code change) should be indicated.

To Reproduce

$ dcm2json -h
[...]
-N,--encode-as-number encode DS, IS, SV and UV values as JSON
numbers; by default DS, IS, SV and UV
values are encoded as JSON strings
[...]

For example:

% dcmtk-3.6.6/dcmdump input.dcm | grep SV 
(0017,100f) SV 1499816949527975237                      #   8, 1 Unknown Tag & Data

leads to:

$ dcm4chee-5.22.6/bin/dcm2json --encode-as-number input.dcm
[...]
   "0017100F" : {
      "Value" : [
         1499816949527975237
      ],
      "vr" : "SV"
   },

Expected behavior

I would have expected two behaviors:

1. An error stating that number: 1499816949527975237 cannot be represented in JSON
2. Explicit quote of the number (eventhough option encode-as-number is passed)

[gunterze]

JSON (in opposite to Java Script) does not limit number of digits of integer values!

[malaterre]

Sorry forgot to quote the actual RFC in the original bug report.

• https://tools.ietf.org/html/rfc7159#section-6

This specification allows implementations to set limits on the range
and precision of numbers accepted. Since software that implements
IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is
generally available and widely used, good interoperability can be
achieved by implementations that expect no more precision or range
than these provide, in the sense that implementations will
approximate JSON numbers within the expected precision. A JSON
number such as 1E400 or 3.141592653589793238462643383279 may indicate
potential interoperability problems, since it suggests that the
software that created it expects receiving software to have greater
capabilities for numeric magnitude and precision than is widely
available.

Note that when such software is used, numbers that are integers and
are in the range [-(253)+1, (253)-1] are interoperable in the
sense that implementations will agree exactly on their numeric
values.

[malaterre]

Same here:

• https://262.ecma-international.org/5.1/#sec-4.3.19

4.3.19 Number value
primitive value corresponding to a double-precision 64-bit binary format IEEE 754 value

NOTEA Number value is a member of the Number type and is a direct representation of a number.

[gunterze]

Allowing implementations to set limits is not equals to specifying a limit. And JSON != ECMA-262.
Anyway, I agree, that it causes lesser troubles to silently ignore --encode-as-number for values outside the 64-bit binary format IEEE 754 range.