Facil.io: A micro-framework for C web applications(github.com)
github.com
Facil.io: A micro-framework for C web applications
https://github.com/boazsegev/facil.io
44 comments
I think this trick comes from Ben Klemens' "21st Century C".
If you like this, the book has some other tricks in it you might also like. (One example: you can define generic functions in C11).
If you like this, the book has some other tricks in it you might also like. (One example: you can define generic functions in C11).
> I haven't seen anything like this before in C or C++, and now I would wish for it to become standard.
I've seen people try to simulate this in C++ with tags.
I've seen people try to simulate this in C++ with tags.
Yes, this exactly - as soon as I saw that, I was like “how did he pull that off?”.
Of course, the first comment on HN has the answer.
I am going to try this trick out today.
Of course, the first comment on HN has the answer.
I am going to try this trick out today.
The exact line is here:
https://github.com/boazsegev/facil.io/blob/master/lib/facil/...
I've seen other hacks to do this, but this is the cleanest that I've seen. He uses the same name for the macro and the function.
The only thing I would change is the way the struct is passed. I would pass by reference.
I really like this.
https://github.com/boazsegev/facil.io/blob/master/lib/facil/...
I've seen other hacks to do this, but this is the cleanest that I've seen. He uses the same name for the macro and the function.
The only thing I would change is the way the struct is passed. I would pass by reference.
I really like this.
> I would pass by reference.
Interesting. I expected taking the address of a struct literal to be illegal, but GCC and Clang both accept it. It does make sense, I guess.
But may I ask why you would pass it by reference? With old ABIs, the struct would be passed on the stack (i.e., by reference) anyway, and with more recent ones, a small prefix would be in registers but the rest passed by reference as well. So why bother manually cluttering the code?
Interesting. I expected taking the address of a struct literal to be illegal, but GCC and Clang both accept it. It does make sense, I guess.
But may I ask why you would pass it by reference? With old ABIs, the struct would be passed on the stack (i.e., by reference) anyway, and with more recent ones, a small prefix would be in registers but the rest passed by reference as well. So why bother manually cluttering the code?
That's really cool, but don't unassigned fields have undefined values? How would the function know what was set? I imagine that in practice they're almost always 0, but that's not guaranteed, right? You'd need to set the struct as {0}, to have everything be 0. Is this a feature of a new(ish) standard?
It is guaranteed per C99. It's a compound initializer.
Also if you set a struct with {1} the first field is set to 1 and the rest to 0. AFAIR it was always like that (at least since standardized C, but probably earlier).
Also if you set a struct with {1} the first field is set to 1 and the rest to 0. AFAIR it was always like that (at least since standardized C, but probably earlier).
C99 specifies that struct literals with absent fields are assigned a zero value. (Notably unspecified is the value of any implicit padding bytes in the struct.)
If you want to do web applications in C, you may also be interested in the kcgi[1] and ksql[2]. kcgi takes a more traditional approach by using CGI rather than embedding a static file server in the final binary.
[1] https://kristaps.bsd.lv/kcgi/
[2] https://kristaps.bsd.lv/ksql/
[1] https://kristaps.bsd.lv/kcgi/
[2] https://kristaps.bsd.lv/ksql/
CGI adds simplicity and interoperability but takes away control and performance. FastCGI suffers from the same fundamental issue as well but to a lesser extent.
There is also Ulfius: https://github.com/babelouest/ulfius/
Honset curiosity: is there a reason Golang or rust couldn't perform same or better? I get why as a programmer I would use C, but what benefit does it have for the users of the app?
Sure. Go is a garbage-collected language with an immature and unsophisticated compiler toolchain, compared to the big free C compilers like GCC or Clang. The compiler limitations are solvable but GC is a core part of the language. Interoperability with C libraries is possible but not great.
Rust is built on LLVM, much like Clang. C integration is relatively easy. I think this is more viable than Go. Unfortunately, Rust is only portable to platforms LLVM supports. While that covers the majority of commonly used hardware today, it is not comprehensive. Also, Rust compile times are pretty bad, especially for optimized builds.
At the end of the day the author gets to write code in a language of their choice to scratch their own itch. End users don't care at all what language a web framework is written in.
Rust is built on LLVM, much like Clang. C integration is relatively easy. I think this is more viable than Go. Unfortunately, Rust is only portable to platforms LLVM supports. While that covers the majority of commonly used hardware today, it is not comprehensive. Also, Rust compile times are pretty bad, especially for optimized builds.
At the end of the day the author gets to write code in a language of their choice to scratch their own itch. End users don't care at all what language a web framework is written in.
Rust is no more a garbage collected language than C is. Just as one can implement reference counting in C, one can do the same in Rust, but it is not forced on you just like it is not forced on you in C.
I consider the standard libraries part of the language. C stdlib does not include ref counting, nor is there any refcounting construct available without building it yourself. Rust obviously has Rc<> and Arc<>.
> Rust obviously has Rc<> and Arc<> and uses it widely in the standard library.
No, it's not. None of the core data structures (String, Vec, HashMap, BTreeMap, VecDeque), for example, use it.
Rust is not a garbage collected language in any meaningful sense of the word. Its runtime is approximately the same size as C's, and the vast majority of all memory management in the Rust ecosystem is done with traditional malloc/free calls. The only difference between Rust and C at this level is that Rust inserts those calls for you automatically. In exchange, the space of programs accepted by the Rust compiler is smaller than what is accepted by a C compiler.
> At the moment it is a garbage-collected language but IIRC they are trying to move away from that as a requirement.
No, we're not. Because no such requirement exists and the vast majority of Rust code doesn't use reference counting at all. If anything, there are some folks that have looked into adding tracing garbage collection to Rust as a library.
No, it's not. None of the core data structures (String, Vec, HashMap, BTreeMap, VecDeque), for example, use it.
Rust is not a garbage collected language in any meaningful sense of the word. Its runtime is approximately the same size as C's, and the vast majority of all memory management in the Rust ecosystem is done with traditional malloc/free calls. The only difference between Rust and C at this level is that Rust inserts those calls for you automatically. In exchange, the space of programs accepted by the Rust compiler is smaller than what is accepted by a C compiler.
> At the moment it is a garbage-collected language but IIRC they are trying to move away from that as a requirement.
No, we're not. Because no such requirement exists and the vast majority of Rust code doesn't use reference counting at all. If anything, there are some folks that have looked into adding tracing garbage collection to Rust as a library.
> In exchange, the space of programs accepted by the Rust compiler is smaller than what is accepted by a C compiler.
The space of safe programs accepted by Rust is indeed smaller, but you can use the `unsafe` keyword if that is an issue. There are even automated transpilers from C to `unsafe` Rust.
The space of safe programs accepted by Rust is indeed smaller, but you can use the `unsafe` keyword if that is an issue. There are even automated transpilers from C to `unsafe` Rust.
As far as I know rust isn't garbage collected
Reference counting is a form of GC.
https://words.steveklabnik.com/borrow-checking-escape-analys...
https://words.steveklabnik.com/borrow-checking-escape-analys...
Rust doesn't do runtime garbage collection. It "garbage collects" at compile time, in a highly optimized way, the same way a human would by manually writing "free". My understanding is that Rust does this well enough that there isn't really a performance cost compared to C.
Edit: I see your other comment about the use of Arc and Rc in the stdlib, that is a good point. However, how much does that actually matter? I'm genuinely curious, my guess is that it is not significant, but I'm not well informed. For example, would that affect embedded use cases?
Edit: I see your other comment about the use of Arc and Rc in the stdlib, that is a good point. However, how much does that actually matter? I'm genuinely curious, my guess is that it is not significant, but I'm not well informed. For example, would that affect embedded use cases?
The users of the framework, the programmers of a webapp? I imagine that there's few frameworks for web development in C, so having options is good.
It's also probably way more portable than Golang or rust. That's also useful for the users of the webapp if they want to host it. I mean, it probably takes less effort to get it to compile and run on a system like SCO, compared to doing that with Golang or rust. You'd think legacy systems don't matter, but I imagine that there's still many businesses that heavily depend on such legacy systems because the costs to safely migrate are big.
Making it in C is probably also going to result in far smaller compiled code, since I imagine C requires a far smaller RTS than Golang or rust. That might make a difference for people that for some reason want to run a webapp on a small device.
I may be wrong though, since I don't have any experience with Golang or rust.
It's also probably way more portable than Golang or rust. That's also useful for the users of the webapp if they want to host it. I mean, it probably takes less effort to get it to compile and run on a system like SCO, compared to doing that with Golang or rust. You'd think legacy systems don't matter, but I imagine that there's still many businesses that heavily depend on such legacy systems because the costs to safely migrate are big.
Making it in C is probably also going to result in far smaller compiled code, since I imagine C requires a far smaller RTS than Golang or rust. That might make a difference for people that for some reason want to run a webapp on a small device.
I may be wrong though, since I don't have any experience with Golang or rust.
I meant the users of the webapp.
The example has functions' string parameters and separate parameters for the string's length. Is this really necessary what happens if the declared length is more than the actual length?
Actually, it's to allow for non-NUL terminated strings.
A good example is when using a String supplied by a scripting language such as Ruby or JavaScript.
Normally, you might need to copy the string to add a NUL byte, or request that the scripting engine provide a NUL terminated string (which might result in the same action performed).
Using this optional approach, a potential copy of the data can be avoided.
A good example is when using a String supplied by a scripting language such as Ruby or JavaScript.
Normally, you might need to copy the string to add a NUL byte, or request that the scripting engine provide a NUL terminated string (which might result in the same action performed).
Using this optional approach, a potential copy of the data can be avoided.
Knowing nothing about this, I would guess that this is to allow sending binary data that contains embedded null bytes?
Though I guess it would be good to have nicer wrappers for the common case where you do only send text.
Though I guess it would be good to have nicer wrappers for the common case where you do only send text.
Probably they use length-prefixed strings internally (which is probably a requirement for taking a C web framework seriously), but allow C nul-terminated strings at the API boundary for convenience of use.
No it is not necessary.
If no length is given, the string is assumed to be NULL-terminated.
It's a bit unfortunate that they use two code paths for that which are basically just copy & paste.
https://github.com/boazsegev/facil.io/blob/master/lib/facil/...
It's a bit unfortunate that they use two code paths for that which are basically just copy & paste.
https://github.com/boazsegev/facil.io/blob/master/lib/facil/...
This approach moves an `if` statement out of the loop, so there's no need to repeat it.
[deleted]
Where's TLS? And http/2?
People who serve SSL out of their Java servlets by installing certificates to random Tomcat and Linux system directories are already a little crazy.
You'd have to be a real maniac to serve TLS in someone's random C framework.
You'd have to be a real maniac to serve TLS in someone's random C framework.
Pretty cool! but it doesn't support HTTP2 which is a bit disappointing
Very few folks don’t run some reverse proxy in front of their application servers (or a whole string of them to load balance), so lack of http/2 on an application server is rarely a dealbreaker for a web framework. I’ll take a solid framework with only h/1.1 over an iffy one with h/2 any day of the week.
The FreeBSD project has been dealing with HTTP2 interoperability hell over the last month. (Curl 7.62 may or may not talk to Phabricator if HTTP2 is enabled; it seems to depend on some local conditions and the phase of the moon whether it works or not. HTTP1.1 just works.) Given that experience with HTTP2, I'm quite happy to stick to HTTP1.1 for now.
HTTP1.1 is expected to just work it has been here for a very long time. It takes time to understand, support and adopt new technology. I'm not sure if the blame should be on HTTP2 in this case.
Regardless of who the blame should land on — I don't have a strongly held opinion about that — the point remains that HTTP1.1 is a super old, well understood, relatively simple protocol that everyone has done correctly for years. In comparison, HTTP2 is the new, more complex thing and it's understandable there are growing pains and incompatibilities. I just don't want to debug those issues in something that worked great for me on HTTP1.1.
only thing i did not understand is port being string/char*
other than that, clever api
other than that, clever api
Probably for getaddrinfo():
http://beej.us/guide/bgnet/html/single/bgnet.html#getaddrinf...
http://beej.us/guide/bgnet/html/single/bgnet.html#getaddrinf...
It's simulated cleverly using a macro that wraps variable arguments in a struct literal: See the definition of http_set_cookie in https://github.com/boazsegev/facil.io/blob/master/lib/facil/...