Fix handling of -Infinity during json parsing #706
Conversation
shivaprasad-basavaraj
force-pushed
the
fixInfJSONParsing
branch
from
bc4ca4e
to
17d9a8e
Compare
| ConstCStr specialIEEEVals[] = { "infinity", "-infinity", "inf", "-inf", "nan", nullptr}; | ||
| ConstCStr* specValPtr = specialIEEEVals; | ||
| while (*specValPtr) { | ||
| if (token.ComparePrefixCStrIgnoreCase(*specValPtr)) { |
There was a problem hiding this comment.
The behavior of the UnflattenFromJSON node should match LabVIEW's Unflatten From JSON which is stricter about the allowed representations:
The TDViaParser is used both for parsing VIA text content and for implementing the UnflattenFromJSON node. We kind of use Fmt().UseFieldNames() as a hint that we are doing the UnflattenFromJSON semantics for parsing. We should either use that as a hint to make sure that the UnflattenFromJSON node will align behavior with LabVIEW or add a new hint for this use-case, something like Fmt().LabVIEWJSONExtensions() since this is JSON extensions that are LabVIEW-specific.
| @@ -1074,6 +1074,21 @@ Boolean TDViaParser::EatJSONItem(SubString* input) | |||
| return true; | |||
There was a problem hiding this comment.
@shivaprasad-basavaraj Our PR workflow also includes making sure the squad workflow tests are run with the local changes and including a link to the CI build (Ideally also with some tests added on the ASW side as well). Example Vireo PR with referenced build links.
Part of #703
The issue was that we were checking only against the leading character of the token in JSON to determine if a value was Infinity or Nan which led to us misidentifying -Infinity as not a Inf or Nan value. Changed the cheks to compare the whole token.
Added a via test for this case.