Show HN: Very low footprint JSON parser in portable ANSI C
1–10 of 58 posts
Re: Show HN: Very low footprint JSON parser in portable ANSI C
#2Here's another minimalist alternative: https://bitbucket.org/zserge/jsmn/wiki/Home
I've used it and think it's pretty neat. One of these days I'll get around to releasing the helper functions we've written to make it easier to use too.
Re: Show HN: Very low footprint JSON parser in portable ANSI C
#3Seems similar to the one up on CCAN [1], which is also BSD-MIT licensed.
EDIT: forgot to mention that it includes a bunch of great helper functions, too.
Re: Show HN: Very low footprint JSON parser in portable ANSI C
#4Any reason you roll your own numeric() instead of using isdigit()? It's in C89.
Re: Show HN: Very low footprint JSON parser in portable ANSI C
#5Any reason you roll your own numeric() instead of using isdigit()? It's in C89.
Just to be sure it's inlined, really. Although I assume isdigit would be, being a compiler built-in.
Re: Show HN: Very low footprint JSON parser in portable ANSI C
#6why 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 (maybe i am missing some c trick here?)?
[not dissing you, just bored on a sunday afternoon...]
Re: Show HN: Very low footprint JSON parser in portable ANSI C
#7On a related note, if you want to get something done on a sunday afternoon, writing a simple recursive descent JSON parser from scratch is both doable and fun.
Re: Show HN: Very low footprint JSON parser in portable ANSI C
#8I like using Jansson: http://www.digip.org/jansson/
Re: Show HN: Very low footprint JSON parser in portable ANSI C
#9why 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 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?
There's only two passes, and it increments the length on both (the first is to measure the string, the second is to know where to write in it).
> what is "[..] cur_value" supposed to do at the top of json_value_free (maybe i am missing some c trick here?)?
You're not supposed to mix code and value declarations in ANSI C, so I put it at the top of the function. It's just used to temporarily store the value while reading the parent.
Re: Show HN: Very low footprint JSON parser in portable ANSI C
#10why 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…
ha. on the last one i was confused by your spaces - thought it was a multiplication... (sorry)
[edit] on the bitfield / enum question, i've been looking around for a consistent, standard way of doing things and there doesn't seem to be any one best practice (although various people note that bit fields are normally unsigned ints, while enums are signed).