bugGPSD - Bugs: bug #53150, JSON parser can not handle a...

 
 

bug #53150: JSON parser can not handle a double that is a NaN

Submitter:  Gary E. Miller <garyemiller>
Submitted:  Tue 13 Feb 2018 11:32:57 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 31 May 2019 11:33:48 AM UTC, comment #4: 

The requested enhancement for the C JSON parser is not practical.

The problem is this: we can declare a C receiver structure that's type-polymorphic, sometimes float and sometimes string.  But a NaN or Inf literal isn't a string.  We'd be outside the JSON specification here.

So there's no way to pass a NaN or Inf through JSON other than by choosing an in-band (float) sentinel value and/or giving up and passing "NaN" etc as strings. The latter would be pretty nasty to deal with on the client side.  I can imagine how to do this, but writing the static receiver declarations is already scary enough without the contortions it would require.  Such code would be a major defect attractor.

Because ECEF values have a restricted range, declaring (finite) sentinel values that signal NaN/Inf ought to work and would be much simpler.  We're just going to have to bite the bullet and do real NaN checks on the way into JSON.

Please refile this on GitLab with a title like "NaN/Inf must be encoded by documented finite sentinel values in JSON".


Eric S. Raymond <esr>
Group administrator
Wed 26 Dec 2018 07:08:44 PM UTC, comment #3: 

"Json.NET no longer serializes NaN and positive and negative infinity floating point values as symbols, which is invalid JSON. With 5.0 the new default is to serialize those values as strings, e.g. "NaN" instead of NaN. There is no change to serializing normal floating point numbers."

http://james.newtonking.com/archive/2013/04/07/json-net-5-0-release-1-net-4-5-biginteger-read-only-collections

Gary E. Miller <garyemiller>
Group administrator
Wed 26 Dec 2018 07:07:09 PM UTC, comment #2: 


> How does this come up? Who is passing NaNs to the parser?


Any float could be a NaN, +Inf or -Inf.  We keep finding ones that are not properly checked before becoming JSON.  isnan() is not a proper check.

Also some of the floating point math in gpsd could potentially raise a NaN.

Regardless of how, JSON should not crash on NaN, +Inf or -Inf.  Those are valid values for a float.  A lot of code could be removed if JSON handled NaN, +Inf and -Inf.

Gary E. Miller <garyemiller>
Group administrator
Wed 26 Dec 2018 06:49:44 PM UTC, comment #1: 

How does this come up? Who is passing NaNs to the parser?

Eric S. Raymond <esr>
Group administrator
Tue 13 Feb 2018 11:32:57 PM UTC, original submission:  

The JSON parser can not handle a double that is a NaN.  This comes up in the new ECEF code.

Gary E. Miller <garyemiller>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by esr (Posted a comment)
  • -email is unavailable- added by garyemiller (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-05-31 esr Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code