JSMN VS c4

Like how https://github.com/zserge/jsmn works. I thought it would be neat to have such as parser for https://github.com/vshymanskyy/muon

One more JSON implementation using this approach is https://github.com/zserge/jsmn.

Yep! I'm using JSMN (https://github.com/zserge/jsmn), which is a streaming parser that visits each token sequentially, so there's only one copy of each JSON response in memory. I also avoid allocating new intermediate memory whenever possible; for example, to unescape backslashes in the JSON strings, I use a destructive loop that moves the non-backslash characters forward in memory, and truncates the string by moving the null terminator earlier in the string. Not something I'd imagine doing in most environments today, but as you said, it saves a bit of space at the expense of CPU time :)

  void DestructivelyUnescapeStr(LPSTR lpInput) {

After reviewing several options, I’ve settled on plain old JSON. For parsing, I use https://github.com/zserge/jsmn. For serialization I use https://github.com/rdpoor/jems (disclaimer: I wrote the latter, but others use it as well).

As mentioned here, it appears that tiny-json is a parser, not a serializer. If you're looking for parsers, I've been very happy with jsmn.

Very small, 4-5 fields but I'm still going to write in binary because I'm trying to reduce dependencies and https://github.com/zserge/jsmn looks like good fit but jsmn only does parsing which I need for parsing some Oauth json data and config.json file. I will be able to dump the state struct in a state.bin file and read it later for comparing it with system time. Not having to write in text fits well for this particular use case. Benefits: Reduced dependencies and almost cost less decoding of the state struct(which the user will never see).

This is my very straight-forward implementation that came to be from the lack of JSON encoding in jsmn:

The C4 compiler [https://github.com/rswier/c4] is a self-hosting compiler for a subset of the C programming language that produces executable x86 code. You can understand and audit this code in a couple of hours (its 528 lines).

It could be an interesting exercise to bootstrap up from something like this to a working linux environment based solely on source code compilation : no binary inputs. Of course a full linux environment has way too much source code for one person or team to audit, but at least it rules out RoTT style binary compiler contamination.

I was surprised to see nodes still have two pointers ("references") given that you now know that that the first pointer will always point exactly to the next node. I've see https://github.com/rswier/c4 use that. Granted it doesn't make for the most readable code, but it's even smaller and faster.

VMs with simple instruction sets is a fun topic. Some years ago I got inspired by the amazing rswier/c4 compiler by Robert Swierczek and explored the smallest instruction set I could get away with to create VMs that could run non-trivial workloads.

C4 comes to mind (C in 4 functions), https://github.com/rswier/c4.

have you considered adding a backend for LLVM? perhaps a bit heavyweight, but it could be a good way to get C/C++, fortran, rust, etc. if that's something you'd like!

I use Alpine Linux (no GNU bloat btw), dwm (Sucks less!), and I edit all my C (no bloat language) through busybox ed and compile my programs with (c4)[https://github.com/rswier/c4]

Keep in mind you can create a "usable" C compiler by yourself, and is doable in surprisingly low amount of code. Try https://github.com/rswier/c4/blob/master/c4.c