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"?
Sj.h: A tiny little JSON parsing library in ~150 lines of C99
161–170 of 248 posts
Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99
#162Earlier 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
Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99
#163Earlier 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?
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
#164Earlier 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…
Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99
#165Earlier 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?
Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99
#166The 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. 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
#167What’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).
Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99
#168Earlier 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.
Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99
#169Earlier quoted context omitted.
Parsing JSON is a Minefield (2016) https://seriot.ch/projects/parsing_json.html
Not if I'm also the producer.
Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99
#170Earlier 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.