I see this being useful for embedded/micro-controller use, very nice!
Sj.h: A tiny little JSON parsing library in ~150 lines of C99
121–130 of 248 posts
Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99
#122JSON 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…
Yeah, but as long as I'm not releasing in public, I don't need to support 20 different ways of parsing.
That's the thing with reinventing wheels, a wheel that fits every possible vehicle and runs well in any possible terrain is very difficult to build. But when you know exactly what you need it's a different story.
Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99
#123JSON 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.
Parsing JSON is a Minefield (2016) https://seriot.ch/projects/parsing_json.html
Not if I'm also the producer.
Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99
#124JSON 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.
Anyone who claims "it's not a very difficult problem" hasn't actually had to solve that problem.
Except I have, several times, with gopd results.
So in this case you're wrong.
General purpose is a different can of worms compared to solving a specific case.
Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99
#125Earlier quoted context omitted.
You probably didn't control the other end, as otherwise you would've used something more sane than JSON?
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...)
Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99
#126Earlier quoted context omitted.
There is no easy way out when you're working with C: either you handle all possible UB cases with exhaustive checks, or you move on to another language. (TIP: choose the latter)
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...
Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99
#127Earlier 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.…
I also use Unlicense. It's literally the most permissive license you can have lol
Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99
#128Earlier quoted context omitted.
The license says otherwise; hard to get freer than public domain.
What is the stance of Your Average Corp’s security department on public domain software? Do they accept software under such licensing (or lack thereof)?
From an American perspective, there’s no mechanical difference between that and the MIT license when it comes to security.
They care more about the package being maintained, bug-free, and their preferred vulnerability database showing no active exploits.
At least in my experience, anyway. Other companies may have stricter requirements.
Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99
#129Earlier quoted context omitted.
Open source is a more informative term for this than free software. Not all free software is open source, but all open source software is free. Edit: I was not aware of the FSF's definition. I was using a definition of free software being software that you can use without having to pay for it.
I think you are mistaken; neither is a subset of the other. At the very least, there are licences which are recognised as open source by the OSI, but not as free by the FSF, and vice versa [1]. I think it’s more appropriate to say they are two fundamentally separate definitions with a massive overlap. [1] https://spdx.org/licenses/
Thank you for the information! I was not aware of the FSF's definition.
Re: Sj.h: A tiny little JSON parsing library in ~150 lines of C99
#130Earlier quoted context omitted.
Open source is a more informative term for this than free software. Not all free software is open source, but all open source software is free. Edit: I was not aware of the FSF's definition. I was using a definition of free software being software that you can use without having to pay for it.
> Not all free software is open sourc Depends on which "free software" definition you're referring to. The FSF definition of "free software" requires it to be open source.
I have clarified which definition I used.