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

 
 

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

Submitted by:  Gary E. Miller <garyemiller>
Submitted on:  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

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

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