On Tue, Jun 2, 2009 at 7:06 PM, Oliver Hunt <span dir="ltr">&lt;<a href="mailto:oliver@apple.com">oliver@apple.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So i&#39;ve been looking at the JSON object grammar and have been talking to brendan and i&#39;m getting somewhat conflicting information.<br>
<br>
The grammars on <a href="http://json.org" target="_blank">json.org</a> and in the ES5 spec both prohibit leading 0&#39;s on any number, but the various implementations disagree with this.<br>
<br>
json2.js (from <a href="http://json.org" target="_blank">json.org</a>), ie8, and chrome all support the standard ES octal literal lexer -- eg. JSON.parse(&quot;[010]&quot;)[0] === 8<br>
<br>
SpiderMonkey allows a leading 0 but still interprets it as a decimal value -- eg. JSON.parse(&quot;[010]&quot;)[0] === 10<br>
<br>
It seems to me that the spec needs to be corrected to specify what the behaviour actually is, rather than what we wish it could be.<br>
</blockquote><div><br><br><div class="gmail_quote"><div>Since octal wasn&#39;t an official part of
ES3, remains absent from official ES5, and is now explicitly prohibited
from ES5/strict, it is good that it is not specified by JSON. I am
surprised that json2.js accepts the syntax, and even more surprised
that it interprets it as octal. Although the rfc says<br>
<br><pre>   A JSON parser transforms a JSON text into another representation.  A<br>   JSON parser MUST accept all texts that conform to the JSON grammar.<br>   A JSON parser MAY accept non-JSON forms or extensions.<br></pre>

I think the behavior you state of json2.js, ie8, and chrome should be
considered a bug. I hesitate to make the same statement about
SpiderMonkey, because their behavior falls within both the letter and
spirit of the rfc, while maintaining the subset relationship between
JSON and EcmaScript.<br>
</div></div> </div></div>I asked Crock and he clarified why json2.js has this bug. json2.js relies on eval to parse the json. For safety it guards this eval with regular expressions. These regular expressions are already too complicated to be confident in their safety, so it wasn&#39;t worth adding complexity for a non-safety issue.<br>
<br>As for how json2.js interprets these numbers -- according to eval&#39;s interpretation on the underlying platform.<br clear="all"><br>-- <br>    Cheers,<br>    --MarkM<br>