eclipse-aascw / aas-core-codegen / 35295170671

90%

push

github

Reject non-finite floats in the TypeScript JSON (#716)

JSON knows neither an infinity nor a not-a-number. Up to now the
TypeScript jsonization put a number into the object as it came, leaving
it to `JSON.stringify` to write it out as `null` -- so an infinite or
not-a-number property left the SDK as a JSON document which no longer
said what the instance held. An integer went out unchecked as well,
however large.

As in Python, the TypeScript jsonization had no error channel at all, so
this introduces one. `SerializationError` mirrors the one which
the TypeScript *XML* serialization already has, so that the two sides of
the SDK read alike. Its `path` is a plain string, unlike the structured
`Path` of the de-serialization in this very module: a segment of
the latter carries the JSON value it was read from, and while serializing
there is no such value to carry.

`integerToJsonable` and `numberToJsonable` do the refusing. Mind that
both an integer and a floating-point number are a `number` in TypeScript,
so the former has to ask for `Number.isFinite` *before* it compares
against the range: a not-a-number satisfies neither `<` nor `>`, and
would pass a bare range check unnoticed.

A list of numbers consequently loses its `Array.from` fast path and goes
through `serializeArray`, which now records the index of the item which
is refused. A tuple loses its array literal for the same reason: a literal
has nowhere to record which of its items was refused, so the items are
pushed one by one, and only the ones which can be refused at all are
pushed under a recorded position.

`numberFromJsonable` rejects a non-finite value as well. A conformant
parser can never produce one, but the caller gives us a `JsonValue` which
may have been constructed programmatically.

Only a value which can be refused at all is worth guarding. The
reachability of a number is the same question in every target, so
`collect_ids_of_types_reaching_a_number` and `reaches_a_number` live in
``in... (continued)

111 of 115 new or added lines in 5 files covered. (96.52%)

34656 of 40403 relevant lines covered (85.78%)

2.57 hits per line