Live data from Hacker News

Show HN: Very low footprint JSON parser in portable ANSI C

github.com

11–20 of 58 posts

Re: Show HN: Very low footprint JSON parser in portable ANSI C

#11
There definitely is a lack of good JSON parsers for C. We wrote our own in QEMU. The relevant code is:

http://git.qemu.org/?p=qemu.git;a=blob;f=json-lexer.c;h=3cd3...

http://git.qemu.org/?p=qemu.git;a=blob;f=json-parser.c;h=849...

Among other things, this supports streaming, is fairly fast, and has gotten a fair bit of scrutiny against malicious input.

The lexer is a hand written state machine which seems like something you should never do but turned out to be pretty reasonable.

Re: Show HN: Very low footprint JSON parser in portable ANSI C

#12
I've used cJSON (http://sourceforge.net/projects/cjson/) in the past, which worked very well for what I needed (simple 1 file JSON parser for config files). Maybe I'll give this a shot the next time I need to do some simple JSON parsing.

You should get the project listed on http://www.json.org/

Re: Show HN: Very low footprint JSON parser in portable ANSI C

#13
Is JSON guaranteed to be ASCII?

To clarify: Any "lookup table" that maps hex values to assumed character values is a portability red flag. When using them, it's polite to add comments to explicitly call out the code page dependency and argue (from a spec or RFC, say) why that assumption is okay.

Re: Show HN: Very low footprint JSON parser in portable ANSI C

#14

Is JSON guaranteed to be ASCII? To clarify: Any "lookup table" that maps hex values to assumed character values is a portability red flag. When using them, it's polite to add comments to explicitly call out the code page dependency and argue (from a spec or RFC, say) why that assumption is okay.

http://www.ietf.org/rfc/rfc4627 specifies that the encoding must be Unicode: "JSON text SHALL be encoded in Unicode. The default encoding is UTF-8."

Re: Show HN: Very low footprint JSON parser in portable ANSI C

#15

Is JSON guaranteed to be ASCII? To clarify: Any "lookup table" that maps hex values to assumed character values is a portability red flag. When using them, it's polite to add comments to explicitly call out the code page dependency and argue (from a spec or RFC, say) why that assumption is okay.

http://www.ietf.org/rfc/rfc4627 specifies that the encoding must be Unicode: "JSON text SHALL be encoded in Unicode. The default encoding is UTF-8."

I'm assuming UTF-8, so the characters I'm looking for should match up fine (\u escape sequences are also converted to UTF-8 for output).

Re: Show HN: Very low footprint JSON parser in portable ANSI C

#19
post #9

why are the flag values not enums (and why is 4 missing?)? is using a lookup table for decoding hex really faster than the (minimal) logic (what if it causes cache misses)? do you really think that a state machine with bit flags is the best way to express the logic here? is string_add meant to increment string_length on subsequent passes? what is "json_value * cur_value" supposed to do at the top of json_value_free (…

> why are the flag values not enums (and why is 4 missing?)? What would the advantage of using an enum be? (and I guess I used 4 and then removed it later.) > is using a lookup table for decoding hex really faster than the (minimal) logic (what if it causes cache misses)? No idea, that's just the way I did it. Feel free to try something else and profile if you're really that concerned. > do you really think that a st…

> You're not supposed to mix code and value declarations in ANSI C

You can in C99.

Re: Show HN: Very low footprint JSON parser in portable ANSI C

#20
post #12

I've used cJSON ( http://sourceforge.net/projects/cjson/ ) in the past, which worked very well for what I needed (simple 1 file JSON parser for config files). Maybe I'll give this a shot the next time I need to do some simple JSON parsing. You should get the project listed on http://www.json.org/

If that's the same cJSON I was using a few months ago, I found it a lot more memory-hungry than it needed to be. I was doing some network code with lwIP on an embedded system, so the all-static nature of js0n (with some helper functions) was a better fit for me.
Post reply on HN