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

241–248 of 248 posts

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

#241

Post by account42 »

FooBarBizBazz wrote: post #59
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

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.

It's entirely reasonable for a tiny JSON parser written in C to not deal with JSON files over 0x7fffffff bytes long.

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

#242

Post by account42 »

koito17 wrote: post #126
jeroenhd wrote: post #71

Earlier quoted context omitted.

Very few programming languages default to checked increments. Most Rust or Java programmers would make the same mistake. Writing a function to do a checked addition like in other languages isn't exactly difficult, either.

> Most Rust or Java programmers would make the same mistake. Detecting these mistakes in Rust is not too difficult. In debug builds, integer overflow triggers a panic[1]. Additionally, clippy (the official linter of Rust), has a rule[2] to detect this mistake. [1] https://doc.rust-lang.org/book/ch03-02-data-types.html#integ... [2] https://rust-lang.github.io/rust-clippy/master/index.html#ar...

You can also just use ubsan if you want the runtime checks for overflows in C/C++, no need to switch languages for this.

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

#243

Post by account42 »

zelphirkalt wrote: post #208
jeroenhd wrote: post #71

Earlier quoted context omitted.

Very few programming languages default to checked increments. Most Rust or Java programmers would make the same mistake. Writing a function to do a checked addition like in other languages isn't exactly difficult, either.

Many other languages automatically switch to a big integer number type, or have arbitrary size integers anyway.

Which is a great way to turn an overflow into a denial of service as suddenly algorithms that were optimized for simple integer arithmetic slow to a crawl.

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

#244

Post by account42 »

fizzynut wrote: post #63
ricardobeat wrote: post #31

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

The depth is 32 bit, not the index into the file. If you are nesting 2 Billion times in a row ( at minimum this means repeat { 2 billion times followed by a value before } another 2 billion times. You have messed up. You have 4GB of "padding"...at minimum. You file is going to be Petabytes in size for this to make any sense. You are using a terrible format for whatever you are doing. You are going to need a completel…

> I appreciate that people want to have some pointless if(depth > 0) check everywhere

An after the fact check would be the wrong way to deal with UB, you'd need to check for < INT_MAX before the increment in order to avoid it.

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

#245

Post by account42 »

ranger_danger wrote: post #62
ricardobeat wrote: post #31

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

What is your definition of non-ancient? There are still embedded systems being produced today that don't have 32-bit integers.

And those will need careful review of any code you want to run on them because no one cares about your weird architecture nor should they have to.

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

#246

Post by account42 »

jeroenhd wrote: post #76
naasking wrote: post #55

Earlier quoted context omitted.

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.

I've seen much bigger, though technically that wasn't valid json, but rather structured logging with JSON on each line. On the other hand, I've seen exported JSON files that could grow to such sizes without doing anything weird, just nothing exceeding a couple hundred megabytes because I didn't use the software for long enough. Restricting the input to a reasonable size is an easy workaround for sure, but this limita…

To be fair, anyone who uses a 150 line library without bothering to read it deserves what they get.

And in the spirit of your profile text I'm quite glad for such landmines being out there to trip up those that do blindly ingest all code they can find.

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

#247

Post by ranger_danger »

account42 wrote: post #245
ranger_danger wrote: post #62

Earlier quoted context omitted.

What is your definition of non-ancient? There are still embedded systems being produced today that don't have 32-bit integers.

And those will need careful review of any code you want to run on them because no one cares about your weird architecture nor should they have to.

I wouldn't call 8 or 16-bit microcontrollers (with no concept of a 32-bit int) that are in billions of devices "weird". But ok.

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

#248

Post by mbac32768 »

EasyMark wrote: post #58
mbac32768 wrote: post #38

Earlier quoted context omitted.

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 :)

yeah it seems like every other C++ project uses it
Post reply on HN