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

61–70 of 248 posts

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

#61

Post by jama211 »

skydhash wrote: post #36
layer8 wrote: 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 it has limitations they should be documented though right? especially if they’re security concerns.

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

#62

Post by ranger_danger »

ricardobeat wrote: post #31
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.

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.

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

#63

Post by fizzynut »

ricardobeat wrote: post #31
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.

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 completely custom parser because nothing will fit in memory. I don't care how much RAM you have.

Simply accessing an element means traversing a nested object 2 billion times in probably any parser in the world is going to take somewhere between minutes and weeks per access.

All that is going to happen in this program is a crash.

I appreciate that people want to have some pointless if(depth > 0) check everywhere, but if your depth is anywhere north of million in any real world program, something messed up a long long time ago, never mind waiting until it hits 2 billion.

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

#64

Post by EasyMark »

adrianN wrote: post #3

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

A basic reference for beginners or people looking at doing some simple parsing? Someone who wants a tiny code footprint for a small hobby project on a limited processor? Although in that case I would almost certainly use TOML or similar instead.

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

#65

Post by k_roy »

flykespice wrote: post #52
hypeatei wrote: post #46

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?

Probably more of lack of explicit liability in the license.

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

#66

Post by koolba »

layer8 wrote: post #48
hypeatei wrote: post #43

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.

Hobby projects that prove useful have a tendency of starting to be used in production code, and then turning into CVEs down the road. If there is a conscious intent of disregarding safety as you say, the Readme should have a prominent warning about that.

> 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 ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

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

#68

Post by CorrectHorseBat »

koolba wrote: post #66
layer8 wrote: post #48

Earlier quoted context omitted.

Hobby projects that prove useful have a tendency of starting to be used in production code, and then turning into CVEs down the road. If there is a conscious intent of disregarding safety as you say, the Readme should have a prominent warning about that.

> 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

#69

Post by typpilol »

mbac32768 wrote: post #38
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.

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…

122 million unit tests? What?
Post reply on HN