Live data from Hacker News

Sj.h: A tiny little JSON parsing library in ~150 lines of C99

github.com

81–90 of 248 posts

Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99

#81

Earlier quoted context omitted.

An int will be 32 bits on any non-ancient platform, so this means, for each of those lines: - a JSON file with nested values exceeding 2 billion depth - a file with more than 2 billion lines - a line with more than 2 billion characters

The depth is 32 bit, not the index into the file. If you are nesting 2 Billion times in a row ( at minimum this means repeat { 2 billion times followed by a value before } another 2 billion times. You have messed up. You have 4GB of "padding"...at minimum. You file is going to be Petabytes in size for this to make any sense. You are using a terrible format for whatever you are doing. You are going to need a completel…

[deleted]

Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99

#82
post #19

The library doesn’t check for signed integer overflow here: https://github.com/rxi/sj.h/blob/eb725e0858877e86932128836c1... https://github.com/rxi/sj.h/blob/eb725e0858877e86932128836c1... https://github.com/rxi/sj.h/blob/eb725e0858877e86932128836c1... Certain inputs can therefore trigger UB.

    diff --git a/sj.h b/sj.h
    index 60bea9e..25f6438 100644
    --- a/sj.h
    +++ b/sj.h
    @@ -85,6 +85,7 @@ top:
             return res;
     
         case '{': case '[':
    +        if (r->depth > 999) { r->error = "can't go deeper"; goto top; }
             res.type = (*r->cur == '{') ? SJ_OBJECT : SJ_ARRAY;
             res.depth = ++r->depth;
             r->cur++;
There, fixed it

Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99

#83
post #73

Earlier quoted context omitted.

JSON does not necessarily come from untrusted sources if you control the entire system. Not everything needs to be absolutely 100% secure so long as you control the system. If you are opening the system to the public, then sure, you should strive for security, but that isn't always necessary in projects that are not processing public input. Here's an example - I once coded a limited JSON parser in assembly language.…

Untrusted doesn’t always mean adversarial IMO, even a bitrot can invalidate your entire input and possibly also trigger undefined behaviour if you aren’t prepared to handle that.

UB = "undefined behavior", thanks

Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99

#84
post #41

Earlier quoted context omitted.

An int will be 32 bits on any non-ancient platform, so this means, for each of those lines: - a JSON file with nested values exceeding 2 billion depth - a file with more than 2 billion lines - a line with more than 2 billion characters

2 billion characters seems fairly plausible to hit in the real world

In a single line. Still not impossible, but people handling that amount of data will likely not have “header only and <150 lines” as a strong criteria for choosing their JSON parsing library.

Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99

#85
post #41

Earlier quoted context omitted.

2 billion characters seems fairly plausible to hit in the real world

2GB in a single JSON file is definitely an outlier. A simple caveat when using this header could suffice: ensure inputs are less than 2GB.

Not really. I deal with this everyday. If the library has a limit on the input size, it should mention this.

Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99

#86
post #19

The library doesn’t check for signed integer overflow here: https://github.com/rxi/sj.h/blob/eb725e0858877e86932128836c1... https://github.com/rxi/sj.h/blob/eb725e0858877e86932128836c1... https://github.com/rxi/sj.h/blob/eb725e0858877e86932128836c1... Certain inputs can therefore trigger UB.

There was a nice article [0] about bloated edge cases libraries (discussion [1]). Sometimes, it's just not the responsibility of the library. Trying to handle every possible errors is a quick way to complexity. [0]: https://43081j.com/2025/09/bloat-of-edge-case-libraries [1]: https://news.ycombinator.com/item?id=45319399

The amount of untrusted JSON I parse is very high.

UB is bad.

Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99

#87
post #12

JSON parser libraries in general is a black hole of suffering imo. They're either written with a different use case in mind, or a complex mess of abstractions; often both. It's not a very difficult problem to solve if you only write exactly what you need for your specific use case.

It's astonishing how involved a fucking modern JSON library becomes. The once "very simple" C++ single-header JSON library by nlohmann is now * 13 years old * is still actively merging PRs (last one 5 hours ago) * has 122 __million__ unit tests Despite all this, it's self-admittedly still not the fastest possible way to parse JSON in C++. For that you might want to look into simdjson. Don't start your own JSON parser…

holy shit

Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99

#88

Earlier quoted context omitted.

There is no easy way out when you're working with C: either you handle all possible UB cases with exhaustive checks, or you move on to another language. (TIP: choose the latter)

Very few programming languages default to checked increments. Most Rust or Java programmers would make the same mistake. Writing a function to do a checked addition like in other languages isn't exactly difficult, either.

Yes but those languages have defined overflow.

Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99

#89

Earlier quoted context omitted.

There is no easy way out when you're working with C: either you handle all possible UB cases with exhaustive checks, or you move on to another language. (TIP: choose the latter)

Very few programming languages default to checked increments. Most Rust or Java programmers would make the same mistake. Writing a function to do a checked addition like in other languages isn't exactly difficult, either.

[deleted]

Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99

#90
post #65

Earlier quoted context omitted.

...and what open source software license in the world makes the author liable for damages?

Probably more of lack of explicit liability in the license.

every OSS license I've ever seen is "use at your own risk" essentially. That's how this whole system works.

You find a vulnerability? patch it, push change to repo maintainer.

https://xkcd.com/2347

Post reply on HN