lwan

Yes! The JSON library I wrote for the Zephyr RTOS does this. Say, for instance, you have the following struct: struct SomeStruct { char *some_string; int some_number; }; You would need to declare a descriptor, linking each field to how it's spelled in the JSON (e.g. the some_string member could be "some-string" in the JSON), the byte offset from the beginning of the struct where the field is (using the offsetof() macro), and the type. The parser is then able to go through the JSON, and initialize the struct directly, as if you had reflection in the language. It'll validate the types as well. All this without having to allocate a node type, perform copies, or things like that. This approach has its limitations, but it's pretty efficient -- and safe! Someone wrote a nice blog post about (and even a video) it a wh

The Linux man page (https://man7.org/linux/man-pages/man3/atoi.3.html#VERSIONS) says that POSIX.1 leaves it unspecified. As you found out, it's really something that should be avoided as much as possible, because pretty much everywhere disagrees how it should behave, especially if you value portability. sscanf() is not a good replacement either! It's better to use strtol() instead. Either do what Lwan does (https://github.com/lpereira/lwan/blob/master/src/lib/lwan-co...), or look (https://cvsweb.openbsd.org/src/lib/libc/stdlib/strtonum.c?re...) at how OpenBSD implemented strtonum(3). For instance, if you try to parse a number that's preceded by a lot of spaces, sscanf() will take a long time going through it. I've been hit by that when fuzzing Lwan. Even cURL is avoiding sscanf(): https://daniel.haxx.se/blog/2025/04/07/writing-c-for-cur

I recently implemented a Forth, compatible with the Forth Haiku dialect used by https://forthsalon.appspot.com/ -- it uses a tail call/continuation-passing dispatching method, and performs some rudimentary optimizations. At some point it also spit out some C but I decided to give this feature the axe until it has a better infrastructure for optimizations and codegen. The idea is to use it to drive an LED matrix and have a simple web UI to develop "fragment shaders" in Forth. It's developed as part of the Lwan project, although currently it generates GIF files on the fly rather than drive a LED matrix. The source code is here for those that want to play with it: https://github.com/lpereira/lwan/tree/master/src/samples/for...

This is roughly what my JSON parser does. It does type-checking, albeit without using JSON-schema, but an object descriptor that you have to define to parse and generate JSON. It's been developed for embedded systems (it was written originally for a NATS implementation in the Zephyr RTOS), so it's a bit limited and there's no easy way to know where some parsing/type validation error happened, but the information is there if one wants to obtain it: https://github.com/lpereira/lwan/blob/master/src/samples/tec...

Absolutely useless fun tech demos are the best kind of demos https://github.com/lpereira/lwan - presume this is the web server library you're referring to? Very cool.

You don't have to use a channel for coordination. Here is a lexer implementation (in C!) that very closely follows Rob Pike's talk and uses a ring buffer for coordination and is plenty fast. https://github.com/lpereira/lwan/blob/master/src/lib/lwan-te... If you watch the talk carefully, Rob Pike himself mentions this near the end of the talk.

It's great to see people still using C to make web servers ! But can you clarify what are the "state-of-the-art technologies and solutions?" I just skim the project and think this is not a lot better in term of performance than other servers like Nginx or H2O. There is also Lwan[0], which uses epoll too and has a cool coroutine, router implementation (I implemented a framework for Kotlin/Native on top of it[1]). Another framework having really fast and fancy technologies in it is Seastar[2]. I think implementing kernel bypass, AIO, DPSK stuff makes it the fastest web server around currently. May be you can try to push the boundary with those things, SPDK, aggressive polling, fast router...? [0]: https://github.com/lpereira/lwan [1]: https://github.com/KwangIO/kwang [2]: https://github.com/scylladb/seastar

I like this trick that I use in C. It's limited, as it only matches string prefixes, but it works pretty well in the end: https://tia.mat.br/posts/2018/02/01/more_on_string_switch_in... It allows you to write something like this: https://github.com/lpereira/lwan/blob/master/src/lib/lwan-ti... -- which is generated as a binary search by GCC.

How does it compare to lwan? https://github.com/lpereira/lwan

My toy web server can achieve similar performance using a much more modest hardware (Core i7 2640 laptop), using way less RAM (a few dozen kilobytes). Granted this is also being tested on localhost with static content (no disk I/O) -- but shows that event-driven servers are not that novel or difficult to write: my code weighs around 1700 LOC of (might I say) readable C. Static file serving is also fast (using sendfile(), etc), but needs an overhaul to achieve usable concurrency. Currently there's a ~4x performance drop while serving files, but I'm working on this. (The sources are at http://github.com/lpereira/lwan by the way.)