3 ms·

This is interesting, but how does this do on the conformance tests? https://github.com/nst/JSONTestSuite https://github.com/nst/JSONTestSuite

Lucas_Marchetti 1y ago
Real question, does it manage nested objects ?
- morcus 1y ago
  It seems so: https://github.com/rxi/sj.h/blob/master/demo%2Fobject.c https://github.com/rxi/sj.h/blob/master/demo%2Fobject.c
  - Lucas_Marchetti 1y ago
    yep but how deep can you parse nested into nested etc
    - layer8 1y ago
      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 1y ago
        Easy to add such checks though.
catlifeonmars 1y ago
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).
LegionMammal978 1y ago
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.

Lucas_Marchetti 1y ago

Real question, does it manage nested objects ?

morcus 1y ago
It seems so: https://github.com/rxi/sj.h/blob/master/demo%2Fobject.c https://github.com/rxi/sj.h/blob/master/demo%2Fobject.c
- Lucas_Marchetti 1y ago
  yep but how deep can you parse nested into nested etc
  - layer8 1y ago
    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 1y ago
      Easy to add such checks though.

catlifeonmars 1y ago

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).

LegionMammal978 1y ago

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.