Where c is `json_c', "return c > 127 ? 0xFF : hex_table [c];" always returns false due to the range of types.
Show HN: Very low footprint JSON parser in portable ANSI C
31–40 of 58 posts
Re: Show HN: Very low footprint JSON parser in portable ANSI C
#32What happens when the input length is longer than 2^31? You used an "int" for the length (also, why ever use a signed value for length?) --- even on LP64, that counter wraps at ~32 bits.
(Same question applies to how you handle the max_memory computation).
Re: Show HN: Very low footprint JSON parser in portable ANSI C
#33why 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 (…
sizeof(enum) depends on your compilation flags, so enums are bad for library ABIs.
Re: Show HN: Very low footprint JSON parser in portable ANSI C
#34The inline keyword is optional and redundant for member functions defined within a class or struct declaration.
Re: Show HN: Very low footprint JSON parser in portable ANSI C
#35 const json_char *cur_line_begin, *i;
...
top->u.dbl = strtod (i, (json_char **) &i);
top->u.integer = strtol (i, (json_char **) &i, 10);
Re: Show HN: Very low footprint JSON parser in portable ANSI C
#36What are you doing with json.h:121 in _json_value::&operator[](const char* index) when your key doesn't exist?
Still, very nice. Comparable to jsonxx which i've been using up until now.
Re: Show HN: Very low footprint JSON parser in portable ANSI C
#37What are you doing with json.h:121 in _json_value::&operator[](const char* index) when your key doesn't exist? Still, very nice. Comparable to jsonxx which i've been using up until now.
Hmm, what should I do? (since it returns a reference). I could make it a pointer instead, but then you wouldn't be able to chain it.
Maybe some kind of const json_null value to return when the key isn't found.
edit: Done that.
Re: Show HN: Very low footprint JSON parser in portable ANSI C
#38Where c is `json_c', "return c > 127 ? 0xFF : hex_table [c];" always returns false due to the range of types.
Nice catch. It's fixed in the latest version.
Re: Show HN: Very low footprint JSON parser in portable ANSI C
#39What happens when the input length is longer than 2^31? You used an "int" for the length (also, why ever use a signed value for length?) --- even on LP64, that counter wraps at ~32 bits. (Same question applies to how you handle the max_memory computation).
Added some protection against that, thanks.
Re: Show HN: Very low footprint JSON parser in portable ANSI C
#40What are you doing with json.h:121 in _json_value::&operator[](const char* index) when your key doesn't exist? Still, very nice. Comparable to jsonxx which i've been using up until now.
Hmm, what should I do? (since it returns a reference). I could make it a pointer instead, but then you wouldn't be able to chain it. Maybe some kind of const json_null value to return when the key isn't found. edit: Done that.
longjmp to an earlier stage where you can "retract" the error or somehow wrap it in a chainable form (e.g. add a union to your result to signal whether it's a value or error, or whatever)
That's what exceptions are supposed to do. C doesn't have exceptions, so you use setjmp/longjmp.