Live data from Hacker News

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

github.com

161–170 of 248 posts

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

#161
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.…

> Not everything needs to be absolutely 100% secure so long as you control the system. Isn't that a bit like saying "you don't have to worry about home security as long as you are the only person who has the ability to enter your house"?

Not at all.

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

#162
post #66

Earlier quoted context omitted.

> If there is a conscious intent of disregarding safety as you say, the Readme should have a prominent warning about that. What do you consider this clause in the LICENSE: >> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR…

A standard clause you can find in every open source license? It doesn't say anything about how serious the project takes security

You write only Rust code don't you?

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

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

Open Source is about sharing knowledge.

They are sharing their knowledge about how to create a tiny JSON parser. Where is the problem again?

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

#164
post #33

Earlier quoted context omitted.

The problem in the present case is that the caller is not made aware of the limitation, so can’t be expected to prevent passing unsupported input, and has no way to handle the overflow case after the fact.

Do you not review libraries you add to your project? A quick scan of the issues page if it's on a forge? Or just reading through the code if it's small enough (or select functions)? Code is the ultimate specification. I don't trust the docs if the behavior is different from what it's saying (or more often fails to mention). And anything that deals with recursive structures (or looping without a clear counter and chec…

If you review libraries, why do you need to quick scan the issues? You would have already identified all the issues right? Right?

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

#165

Earlier quoted context omitted.

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?

None. That is how RedHat makes money.

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

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

> Sometimes, it's just not the responsibility of the library.

Sometimes. In this case, where the library is a parser that is written in C. I think it is reasonable to expect the library to handle all possible inputs. Even corner cases like this which are unlikely to be encountered in common practice. This is not "bloat" it is correctness.

In C, this kind of bug is capable of being exploited. Sure, many users of this lib won't be using it in exposed cases, but sooner or later the lib will end up in some widely-used internet-facing codebase.

As others have said, the fix could be as simple as bailing once the input size exceeds 1GB. Or it could be fine-grained. Either-way the fix would not "bloat" the codebase.

And yes, I'm well aware of the single-file C library movement. I am a fan.

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

#167
post #3

What’s the usecase for something like this? There are lots of excellent libraries for json available. Is this a teaching tool?

Being able to parse without a lot of overhead and without allocations is quite interesting. E.g. when you process some massive json dump to just extract some properties (the Wikidata dumps come to mind).

If you want to do that you'd probably want to use a fast SAX parser, not something that naively looks at one byte at a time.

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

#168
post #51

Earlier quoted context omitted.

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

Why play all these semantic games? You're saying it's the author's problem. You want them to even edit their readme to include warnings for would be production/business users who don't want to pay for it.

[flagged]

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

#169
post #123
post #42

Earlier quoted context omitted.

Parsing JSON is a Minefield (2016) https://seriot.ch/projects/parsing_json.html

Not if I'm also the producer.

Finally, I have found someone who understands the purpose of using someone else's tiny header-only C library; someone who sincerely thought about it before looking for an excuse to bitch and complain.

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

#170
post #39

Earlier quoted context omitted.

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

Strongly disagree here because JSON can come from untrusted sources and this has security implications. It's not the same kind of problem that the bloat article discusses where you just have bad contracts on interfaces.

It's too bad this header-only JSON library doesn't meet your requirements. How much did you pay for your license to use it? I'm sure the author will be happy to either ship security fixes or give you a refund. You should reach out to him and request support.
Post reply on HN