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

141–150 of 248 posts

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

#141

Post by shiomiru »

captbaritone wrote: post #107
tonypapousek wrote: post #99

Earlier quoted context omitted.

The license says otherwise; hard to get freer than public domain.

I recall hearing that SQLite actually had some significant issues with choosing public domain as their license and somewhat regret the decision. Apparently it’s not a concept which has broad understating internationally, and there’s less legal precedent in a software context which has made it harder for some teams to adopt due to concerns from legal departments.

The Unlicense isn't "just" public domain though, it also has a fallback clause that explicitly lists things you are allowed to do ("copy, modify, publish, use, compile, sell, or distribute"). So I think the intent is, even if PD isn't recognized and line 1 is invalid, you're still granting a license to the same effect.

SQLite on the other hand just says

    The author disclaims copyright to this source code.  In place of a legal
    notice, here is a blessing:

      May you do good and not evil.
      May you find forgiveness for yourself and forgive others.
      May you share freely, never taking more than you give.
which seems less useful once you strike sentence 1.

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

#142

Post by satvikpendem »

F3nd0 wrote: post #108
maldonad0 wrote: post #97

Earlier quoted context omitted.

It's open source, not free software.

‘Free software’ and ‘open source software’ (as respectively defined by the FSF [1] and the OSI [2], which is how they’re usually used in practice) have overlapping definitions. The project in question is released into the public domain via the Unlicense, which qualifies as a free software ‘licence’. Many of the other projects use the MIT/Expat licence, which also qualifies as a free software licence. [1] https://www.…

If anyone is curious on FSF's comments about various licenses: https://www.gnu.org/licenses/license-list.en.html

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

#143

Post by hackernewds »

LiamPowell wrote: post #98

This is rather lenient. There's not anything wrong with that (although perhaps it should be noted for people that will use it without looking at the code), but it's the main reason this can be so small. Using their demo in the readme: {"x",10eee"y"22:5,{[:::,,}]"w"7"h"33 rect: { 10, 22, 7, 33 }

so it is wrong?

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

#144

Post by modeless »

layer8 wrote: post #140
modeless wrote: post #137

Earlier quoted context omitted.

I wouldn't expect a library like this to be secure. If you want it to be memory safe, compile it with Fil-C.

This has nothing to do with memory safety.

This is an overstatement. Yes, UB does not necessarily cause a violation of memory safety, but triggering UB alone is not the goal of an attacker. UB is a means to an end and the end is usually a violation of memory safety leading to arbitrary code execution.

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

#145

Post by jcalvinowens »

habibur wrote: post #134
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.

Will trigger UB if level depth is > 2 billion or in the 2nd case number of lines > 2 billion. Limit you JS input to 1 GB. I will have more problems in other portions of the stack if I start to receive a 2 GB JSON file over the web. And if I still want to make it work for > 2GB, I would change all int in the source to 64 bits. Will still crash if input is > 2^64. What I won't ever do in my code is check for int overfl…

> What I won't ever do in my code is check for int overflow

Amen. Just build with -fno-strict-overflow, my hot take is that should be the default on Linux anyway.

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

#146

Post by layer8 »

ethanwillis wrote: post #96
layer8 wrote: 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.

GP is arguing about licences. Yes, formally there is no obligation, and I'm not saying the author has any such obligation.

In the present case, either the missing overflow check in the code is by mistake, and then it's warranted to point out the error, or, as I understood GGGP to be arguing, the author deliberately decided to neglect safety or correctness, and then in my opinion you can't reject the criticism as unwarranted if the project's presentation isn't explicit about that.

I'm not making anything the author's problem here. Rather, I'm defending my criticism of the code, and am giving arguments as to why it is generally good form to make it explicit if a project doesn't care about the code being safe and correct.

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

#147

Post by robmccoll »

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.

Could just change the input len to an int instead of size_t. Not technically the correct type, but it would make it clear to the user that the input can't be greater than 2^31 in length.

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

#149

Post by taminka »

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

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.

> They acknowledge that these things aren't focused on "security" or "features" and that's okay.

where? single header is just a way to package software, it has no relation to features, security or anything such...

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

#150

Post by 0x000xca0xfe »

modeless wrote: post #138
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…

This may say more about C++ than JSON

The best language to handle unusual JSON correctly would probably be Python. It has arbitrary size integers, mpmath for arbitrary precision floats and good Unicode support.
Post reply on HN