Serge Zaitsev

In the days I was learning C that used to be a "good" coding style. In fact, some of my headers still have `#ifndef __FOO_H__` (ncurses, xcb, numpy, freetype etc...

Parsing such array as 3 elements is definitely incorrect, in browser as well: ``` JSON.parse('[1,,3]') SyntaxError: JSON.parse: unexpected character at line 1 column 4 of the JSON data ``` The...

Related to #52

https://github.com/mcast/json-fileops/tree/jsmn/reHGify --- Original comment by: Matthew Astley

/\* Wide character _/ /_ UTF8 not yet implemented. Pretend we didn't see it. */ --- Original comment by: Gabriel Gritsch

@MacGritsch True, I didn't make an escape hatch here for errors. It translates as in [new jsmn_test.c fn](https://github.com/mcast/json-fileops/blob/a662a7d6269b8dde1ef23dcecca00c8989589fb0/jsmn_test.c#L609-L615), `"\\u0000\\u00ff" --> "\x00\xff"` but `"\\u0100" --> "\\u0100"` (unchanged). The plumbing is there,...

Let's vote. I personally don't need such an extension, but if JSMN users find it useful - we can add it either as a wrapper on top of jsmn or...

Hello Serge, Have you had a chance to investigate this issue? Should I re-open this issue in the new github repo? Thank you --- Original comment by: [matthewb_gc](http://bitbucket.org/matthewb_gc)

@pt300 I really like the suggested list of changes. Strict mode by default, compatibility with RFC8259, Arduino package and bitflags - all sounds good. But I want to share my...

Additionally, I would rather invest into advanced documented supersets of JSON, like JSON5, rather than in the undocumented, barely known non-strict mode.