3 ms·
Yep. It's technically incorrect. It seems honoring this type of technical correctness matters a lot. For example, imagine if ECMA added a new feature (e.g. 0-p
by jchook 7y ago
Yep. It's technically incorrect.
It seems honoring this type of technical correctness matters a lot. For example, imagine if ECMA added a new feature (e.g. 0-prefixed octal literals) in 2020..
Another issue: security. Imagine a hacker figured out that you used a mix of JSON parsers on your application (e.g. V8 and jq), and they produced different output.
For a vaguely related example, consider that some URL parsers interpret Ｎ (U+FF2E - fullwidth latin N) as ".", meaning you can sneakily add a ".." to the URL with ＮＮ (see https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-Ne...)
- ComputerGuru 7y agoI believe what you're actually saying is that regardless of whether or not it is technically correct, it would be incorrect (and I agree with you there). My question was more "for inputs not defined as being valid by the spec, is the result undefined (a la C++ UB where anything and everything is legal in response) or is it required to reject said input". The sibling response says extensions are allowed, but that wouldn't come into play if an input is specifically called out as disallowed (vs simply not taken into account whatsoever).
- deleted 7y ago[deleted]
- jchook 7y agoSection 9 of the RFC would indeed technically allow interpreting 01 as you please, but section 6 states: “Numeric values that cannot be represented in the grammar below... are not permitted” Regardless I agree we should not do such things.