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

211–220 of 248 posts

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

#211

Post by nurettin »

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.

I have tsoding fatigue. Took a long time to get him out of the main page. I like the DIY attitude, but it gets old really fast.

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

#212

Post by johnisgood »

olivia-banks wrote: post #154
lioeters wrote: post #8

What I love about this author's work is that they're usually single-file libraries in ANSI C or Lua with focused scope, easy-to-use interface, and good documentation. And free software license. Aside from the posted project, some I like are: - log.c - A simple logging library implemented in C99 - microui - A tiny immediate-mode UI library - fe - A tiny, embeddable language implemented in ANSI C - microtar - A lightwe…

I vendor in log.c all the time for C projects! I had no idea the author was relatively prolific. Would really recommend checking out log.c, it's really easy to hack in what you need to.

Speaking of, I personally use https://zolk3ri.name/cgit/libzklog/about/ because I like the way it looks. :D I used his simple logging library in Go, so might as well.

I used "lite" (text editor in Lua) which has been mentioned under this submission. It is cool, too.

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

#213

Post by stevepotter »

layer8 wrote: post #146
ethanwillis wrote: post #96

Earlier quoted context omitted.

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 unwa…

I understand your point and if I were the author I would want either a disclaimer or a fix. File an issue or make a pr. Filing an issue is quicker and more fruitful than dealing with folks here

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

#214

Post by Someone »

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.

I wouldn’t rate those as very serious issues for this project. They’ll only be triggered if there are over MAX_INT lines or depth levels in the input. Yes, an attacker might be able to do that, but you’d have to put that input in a memory buffer to call this code. On many smaller systems, that will OOM.

Skimming the code, they also are loose in parsing incorrect json, it seems:

    static bool sj__is_number_cont(char c) {
        return (c >= '0' && c cur != r->end && sj__is_number_cont(*r->cur)) { r->cur++; }
        break;
that seems to imply it treats “00.-E.e-8..7-E7E12” as a valid json number.

    case '}': case ']':
        res.type = SJ_END;
        if (--r->depth error = (*r->cur == '}') ? "stray '}'" : "stray ']'";
            goto top;
        }
        r->cur++;
        break;
I think that means the code finds [1,2} a valid array and {"foo": 42] a valid struct (maybe, it even is happy with [1,2,"foo":42})

Those, to me, seem a more likely attack vector. The example code, for example, calls atoi on something parsed by the first piece of code.

⇒ I only would use this for parsing json config files.

Being tiny is one thing, but the json grammar isn’t that complex. They could easily do a better job at this without adding zillions of lines of code.

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

#215

Post by bmn__ »

nurettin wrote: post #211
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.

I have tsoding fatigue. Took a long time to get him out of the main page. I like the DIY attitude, but it gets old really fast.

https://news.ycombinator.com/item?id=44345740

No one cares. Stop complaining or GTFO.

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

#216

Post by Yeask »

zwnow wrote: post #189
Yeask wrote: post #163

Earlier quoted context omitted.

Open Source is about sharing knowledge. They are sharing their knowledge about how to create a tiny JSON parser. Where is the problem again?

Refer to the original comment. Seems like you are incapable of connecting the comment chain.

Have some manners please.

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

#217

Post by HighGoldstein »

typpilol wrote: post #127
F3nd0 wrote: post #108

Earlier quoted context omitted.

‘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.…

I also use Unlicense. It's literally the most permissive license you can have lol

The caveat with the Unlicense is that it doesn't work in some jurisdictions, and the work may be considered literally unlicensed, as in nobody except the copyright owner can use it. In practical terms, of course, I doubt anyone using the Unlicense plans to come after you for copyright infringement, but it's something to keep in mind. This is why many organizations recommend instead using something like CC0, MIT etc.

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

#218

Post by nurettin »

bmn__ wrote: post #215
nurettin wrote: post #211

Earlier quoted context omitted.

I have tsoding fatigue. Took a long time to get him out of the main page. I like the DIY attitude, but it gets old really fast.

https://news.ycombinator.com/item?id=44345740 No one cares. Stop complaining or GTFO.

Au contraire, I think people do care. Now I will continue complaining and raising awareness with renewed fervor.

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

#219

Post by IshKebab »

meindnoch wrote: post #198
IshKebab wrote: post #194

Earlier quoted context omitted.

True, but usually you only need that if your data is so large it can't fit in memory and in that case you shouldn't be using JSON anyway. (I was in this situation once where our JSON files grew to gigabytes and we switched to SQLite which worked extremely well.)

Actually, you'll hit the limits of DOM-style JSON parsers as soon as your data is larger than about half the available memory, 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 (unless you're able to incrementally destroy those parts of the DOM that you're done with). Anyhow, IMO a proper JSON library should offer both, in a layered app…

> 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; half of all memory and all memory are in the same league.

Post reply on HN