Live data from Hacker News

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

github.com

41–50 of 248 posts

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

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

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

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

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

Parsing JSON is a Minefield (2016)

https://seriot.ch/projects/parsing_json.html

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

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

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.

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

#44
post #34

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

All very possible on modern platforms. Maybe more importantly, I won’t trust the rest of the code if the author doesn’t seem to have the finite range of integer types in mind.

Personally, all my C code is written with SEI C Coding Standard in mind.

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

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

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?

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

#46
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?

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.

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

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

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)

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

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

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.

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

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

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

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

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

then that is their problem, not the code author's. If you use a hobby project in production, that's on you
Post reply on HN