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

191–200 of 248 posts

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

#191

Post by Gibbon1 »

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've been tending to use ssize_t for indexes instead of int. Part of the reason was reading someones decent argument that

   for(int i=0; blah blah; i++)
Is actually broken and dangerous on 64 bit machines.

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

#192

Post by a96 »

rerdavies wrote: post #156
ramses0 wrote: post #115

Earlier quoted context omitted.

"Source Available" and "Open Source" (with an OSI-approved license) are the terms you're looking for. "Free as in speech, or free as in beer?" is your rallying cry.

Or Free as in Ebola, in the case of GPL-licensed software. Whatever happened to Free as in Air and Sunshine?

It was enshittified because there was nothing defending it.

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

#193

Post by ncruces »

ghurtado wrote: post #109
leptons wrote: post #73

Earlier quoted context omitted.

JSON does not necessarily come from untrusted sources if you control the entire system. Not everything needs to be absolutely 100% secure so long as you control the system. If you are opening the system to the public, then sure, you should strive for security, but that isn't always necessary in projects that are not processing public input. Here's an example - I once coded a limited JSON parser in assembly language.…

> Not everything needs to be absolutely 100% secure so long as you control the system. Isn't that a bit like saying "you don't have to worry about home security as long as you are the only person who has the ability to enter your house"?

Sure. I don't password protect my (Android) TV like I password protect my (Android) phone, despite both of them allowing authorized access to the same Google accounts, because if someone entered my house I have bigger things to worry than them using my TV.

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

#194

Post by IshKebab »

meindnoch wrote: post #136
IshKebab wrote: post #75

Earlier quoted context omitted.

Extracting the data into objects. Libraries like Serde and Pydantic do this for you. Hell the original eval() JSON loading method did that too.

Then you lose the ability to do streaming.

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

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

#196

Post by oguz-ismail »

Gibbon1 wrote: post #191
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've been tending to use ssize_t for indexes instead of int. Part of the reason was reading someones decent argument that for(int i=0; blah blah; i++) Is actually broken and dangerous on 64 bit machines.

How is ssize_t any better? It's not part of standard C and is only guaranteed to be capable of holding values between -1 and SSIZE_MAX (minimum 32767, no relation to SIZE_MAX).

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

#197

Post by pgen »

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.

The author has kindly provided you with simple, readable, and free code. If you find it incomplete or unsafe, you can always modify it and contribute your changes if you wish to improve it, in accordance with the licence; and thank him while you're at it.

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

#198

Post by meindnoch »

IshKebab wrote: post #194
meindnoch wrote: post #136

Earlier quoted context omitted.

Then you lose the ability to do streaming.

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 approach. That is, a lower level SAX-style parser, on top of which a DOM-style API is provided as a convenience.

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

#199

Post by johnisgood »

leptons wrote: post #73
klysm wrote: post #39

Earlier quoted context omitted.

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.

JSON does not necessarily come from untrusted sources if you control the entire system. Not everything needs to be absolutely 100% secure so long as you control the system. If you are opening the system to the public, then sure, you should strive for security, but that isn't always necessary in projects that are not processing public input. Here's an example - I once coded a limited JSON parser in assembly language.…

I agree. I knew that the JSON is not going to change, so I wrote a 10 lines long parser for it. It is not a JSON parser by any means, but it parses properly what I need it to.

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

#200

Post by johnisgood »

userbinator wrote: post #125
leptons wrote: post #104

Earlier quoted context omitted.

I controlled both ends. There is nothing "insane" about JSON. It's used far and wide for many purposes. The system sending the JSON was based on Nodejs, so it was pretty natural to use JSON. And I did it with JSON just because I wanted to. I'd have had to invent some other protocol to do it anyway, and I didn't feel like reinventing the wheel when it was quite simple to write a basic JSON parser in assembly language,…

For something that simple I'd choose a custom binary protocol or something like ASN.1 instead of JSON. It's easier to generate from a HLL and parse in a LLL (I've also been writing Asm for a few decades...)

I would love to use ASN.1 if other programming languages would match up to Erlang's ASN.1. :(
Post reply on HN