Live data from Hacker News

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

github.com

51–60 of 248 posts

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

#51
post #48

Earlier quoted context omitted.

Hobby projects that prove useful have a tendency of starting to be used in production code, and then turning into CVEs down the road. If there is a conscious intent of disregarding safety as you say, the Readme should have a prominent warning about that.

> Hobby projects that prove useful have a tendency of starting to be used in production code Even if that is true, how is that the authors problem? The license clearly states that they're not responsible for damages. If you were developing such a serious project then you need the appropriate vetting process and/or support contracts for your dependencies.

I didn’t say it’s the author’s problem. It’s a problem with the code.

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

#52
post #45

Earlier quoted context omitted.

So if its a hobby project designed for just a handful of people, its suddenly okay to endanger them due to being sloppy?

This is an open source project that you're not obligated to use nor did you pay for it. Who is it endangering? The license also makes it clear that the authors aren't liable for any damages.

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

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

#54
post #45

Earlier quoted context omitted.

You're not aware of the simplistic, single header C library culture that some developers like to partake in. Tsoding (a streamer) is a prime example of someone who likes developing/using these types of libraries. They acknowledge that these things aren't focused on "security" or "features" and that's okay. Not everything is a super serious business project exposed to thousands of paying customers.

So if its a hobby project designed for just a handful of people, its suddenly okay to endanger them due to being sloppy?

The code nor author don’t endanger anyone. Whoever uses it inappropriately endangers themselves or others.

Why are you using random, unvetted and unaudited code where safety is important?

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

#55
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

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.

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

#56
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.

Or fork and make a few modifications to handle it? I have to admit I haven't looked at the code to see if this particular code would allow for that.

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

#57
post #48

Earlier quoted context omitted.

You're not aware of the simplistic, single header C library culture that some developers like to partake in. Tsoding (a streamer) is a prime example of someone who likes developing/using these types of libraries. They acknowledge that these things aren't focused on "security" or "features" and that's okay. Not everything is a super serious business project exposed to thousands of paying customers.

Hobby projects that prove useful have a tendency of starting to be used in production code, and then turning into CVEs down the road. If there is a conscious intent of disregarding safety as you say, the Readme should have a prominent warning about that.

My personal take is: if the code is good enough, it should be trivial to switch to a better library at the point when needed.

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

#58
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…

Yeah I use this and I think most of friends do too :)

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

#59
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

This might be the right attitude for a max function written in JavaScript, where the calling code has some control over the inputs.

It's the wrong attitude for a JSON parser written in C, unless you like to get owned.

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

#60
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.

Less than INT_MAX, more accurately. But since the library contains a check when decreasing the counter, it might as well have a check when increasing the counter (and line/column numbers).
Post reply on HN