Loading ...
Sorry, an error occurred while loading the content.

Re: Floating point leading zero problem

Expand Messages
  • Douglas Crockford
    ... 0.625 a correct JSON number, and is accepted by org.json.JSONObject and by json2.js.
    Message 1 of 5 , Jan 18, 2010
    • 0 Attachment
      --- In json@yahoogroups.com, "glanca" <guy@...> wrote:
      >
      > I'm using the JSON_Parser C library on one end and the org.json Java library on the other and they don't agree on the encoding for the floating point value 0.625. The diagram on the JSON.org website suggests that the leading zero is okay whereas the RFC4627 specification states that "Leading zeros are not allowed." for numbers. The org.json won't accept the leading zero and the JSON_Parser library won't accept a leading decimal point.
      >
      > Which is right and which is wrong?

      0.625 a correct JSON number, and is accepted by org.json.JSONObject and by json2.js.
    • glanca
      ... right. ... Thanks for the quick feedback guys. Looking further in to what the org.json Java library is doing reveals this comment: /* * If it might be a
      Message 2 of 5 , Jan 19, 2010
      • 0 Attachment
        --- In json@yahoogroups.com, John Cowan <cowan@...> wrote:
        >
        > The org.json implementation is wrong; the JSON_Parser library is
        right.
        >

        Thanks for the quick feedback guys. Looking further in to what the
        org.json Java library is doing reveals this comment:

        /*
        * If it might be a number, try converting it. We support the 0- and 0x-
        * conventions. If a number cannot be produced, then the value will just
        * be a string. Note that the 0-, 0x-, plus, and implied string
        * conventions are non-standard. A JSON parser is free to accept
        * non-JSON forms as long as it accepts all correct JSON forms.
        */

        The word "try" is meant literally in that it uses try blocks and the
        code is throwing an exception when handling the legal string "0.625". I
        consider exceptions to be *of interest* and therefore trap on them and
        the code doesn't throw an exception on the non-standard value ".625",
        thus my confusion when I read the spec. With a leading zero it does
        eventually manage to return the correct Double object but only after
        dumping a stack trace.

        It looks like a simple re-arrangement should resolve my problem but I'm
        not set up to do regression testing against the specifications. For now
        I'll probably just comment out the contents of the catch block (which
        just dumps a stack trace) and if I do try to fix it I'll try sending a
        patch to the anonymous feedback address for the code.

        Thanks again.

        -- Guy




        [Non-text portions of this message have been removed]
      • Mark Joseph
        This is our first release of our combined JSON XML product SDK Press Release: https://www.p6r.com/company/news.html Product Page:
        Message 3 of 5 , May 10, 2010
        • 0 Attachment
          This is our first release of our combined JSON XML product SDK

          Press Release: https://www.p6r.com/company/news.html
          Product Page: https://www.p6r.com/software/xjr.html


          Regards,

          Mark Joseph, Ph.D.
          President
          P6R, Inc
          408-205-0361
          mark@...
          Skype: markjoseph_sc



          [Non-text portions of this message have been removed]
        Your message has been successfully submitted and would be delivered to recipients shortly.