This is interesting, but how does this do on the conformance tests?

LegionMammal978 14 hours ago | parent | next [-]

It doesn't seem to have much in the way of validation, e.g., it will indiscriminately let you use either ']' or '}' to terminate an object or array. Also, it's more lenient than RFC or json.org JSON in allowing '\v' for whitespace. I'd treat it more as a "data extractor for known-correct JSON". But even then, rolling your own string or number parser could get annoying, unless the producer agrees on a subset of JSON syntax.

▲

catlifeonmars 14 hours ago | parent | prev | next [-]

You know what would really be useful is a conformance test based on a particular real implementation.

What I mean by this is a subset (superset?) that exactly matches the parsing behavior of a specific target parsing library. Why is this useful? To avoid the class of vulnerabilities that rely on the same JSON being handled differently by two different parsers (you can exploit this to get around an authorization layer, for example).

▲

Lucas_Marchetti 15 hours ago | parent | prev [-]

Real question, does it manage nested objects ?

▲

morcus 15 hours ago | parent [-]

It seems so: https://github.com/rxi/sj.h/blob/master/demo%2Fobject.c

▲

Lucas_Marchetti 15 hours ago | parent [-]

yep but how deep can you parse nested into nested etc

▲

layer8 15 hours ago | parent [-]

Why don’t you look at the source code, it’s only 150 lines?

The nesting is limited by using an int as the depth counter. The C standard guarantees that MAX_INT is at least 32767, so that’s a limit on portable nesting depth. Nowadays int is typically 32 or 64 bits, so a much higher limit in typical C implementations.

If I see correctly, the library doesn’t check for overflow, however. This might conceivably be an exploitable vulnerability (and such an overflow would constitute UB).

	▲	johnisgood 14 hours ago \| parent [-]
		Easy to add such checks though.