Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

231–240 of 248 posts

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

#231

Post by rerdavies »

xigoi wrote: post #176
rerdavies wrote: post #155

Earlier quoted context omitted.

Kinda depends on whether you're publishing open source software so that people can use it. And if you're not publishing open source software so that people can use it, why exactly are you doing it? If you don't want people to use it, GPL is the way to go. If you do want people to use it, MIT or BSD is a much better way to go.

GPL is for when you want people to use it. MIT is for when you want megacorporations to turn it into enshittified proprietary software and profit off of it without giving back to you.

Sure. Why not?

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

#233

Post by teo_zero »

queuebert wrote: post #220

What is the purpose of declaring an sj_Reader object with an sj_read method if you don't support lazy parsing? Seems like you could tighten up the code by combining the declaration and parsing into one subroutine.

Totally agree! I've never understood the beauty of singleton objects.

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

#234

Post by jama211 »

knowitnone2 wrote: post #164
skydhash wrote: post #36

Earlier quoted context omitted.

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?

Hahaha well said

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

#235

Post by codr7 »

patrickmay wrote: post #100
codr7 wrote: 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.

> JSON parser libraries in general is a black hole of suffering imo. Sexprs sitting over here, hoping for some love.

I still mourn the timeline where we got a real Lisp in the browser instead of the current abomination.

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

#236

Post by IshKebab »

meindnoch wrote: post #224
IshKebab wrote: post #219

Earlier quoted context omitted.

> since you'd most likely want to build your own model objects from the JSON, so at some point both of them must be present in memory Not really because the JSON library itself can stream the input. For example if you use `serde_json::from_reader()` it won't load the whole file into memory before parsing it into your objects: https://docs.rs/serde_json/latest/serde_json/fn.from_reader.... But that's kind of academic;…

That's only true if your model objects are serde structs, which is not desirable for a variety of reasons, most importantly because you don't want to tie your models to a particular on-disk format.

In the vast majority of cases you can and should just load directly into Serde structs and use those directly. That's kind of the point.

In some minority of cases you might not want to do that (e.g. because you need to support multiple versions of a format), but that is rare and can also be handled in various ways directly in Serde.

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

#238

Post by account42 »

layer8 wrote: 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.

Easy enough to fix:

  -sj_Reader sj_reader(char *data, size_t len) {
  +sj_Reader sj_reader(char *data, int len) {
Not everyone needs to waste cycles on supporting JSON files larger than 2^31-1.

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

#239

Post by account42 »

hypeatei wrote: post #46
zwnow wrote: 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.

> The license also makes it clear that the authors aren't liable for any damages.

The license disclaims liability but that doesn't mean the author cannot ever be held liable. Ultimately, who is liable is up to a court to decide.

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

#240

Post by account42 »

klysm wrote: post #39
skydhash wrote: post #26

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.

There is only a problem with these checks here if you pass along arbitrarily large JSON strings as all of these counters are advanced at most once per input byte. If you don't limit the input to reasonable sizes you have a potentional denial of service problem even without the UB so you should be checking for reasonable sizes which depend on your application but are likely much lower than the 2^31-1 bytes the library can safely parse.
Post reply on HN