That implies some global state somewhere being updated, and now you've given up on threading. This may be OK, but it's still dangerous and leaky even if you give up on threading.

There are various solutions that still allow you to pass a set of closures without being particularly more ugly than anything else is in C, for instance, see http://library.gnome.org/devel/gobject/stable/chapter-signal... . C++ still ends up nicer, my point is just that you can do good things in C and there are libraries that implement the stuff for you.

That said, if I were really going this route I probably would try to go with some sort of minimal C++. Then again, my opinion is suspect, as I would never go this route anyhow. Web developers writing in languages that don't permit buffer overflows write software that has all the security of a colander; adding the ability to write good, solid buffer overflows as well hardly seems like a step up. You can write secure C code, but you can write secure PHP code, too. Existence proofs of secure code aren't very interesting.

You're right, web developers already write software with all the security of a colander. You can go one of two ways, 1.) you can devise a language that can't express an insecure application or 2.) you can teach people about security. I know which option I prefer.

Overly reductive. There is an actual security benefit to using environments that minimize memory corruption. Educating devs helps, but educated devs do not reliably avoid memory corruption.

I assume you mean #2? Because here we are in year, oh, 17 or 18 or so of web development give or take a couple of years and that's worked out so well, hasn't it?

It's a beautiful sentiment. It hasn't worked. Handing them new vectors to screw up in is not going to solve the problem.

It also doesn't matter. Hand a developer a tool that requires them to continuously pay attention to an issue and no matter how good they are, at some point they will slip, because they're human. We've tried "teach them about security" a couple hundred times, maybe it's time we try "devise a language that can't trivially express an insecure application". C will not be the language that implements that, it completely lacks any of the necessary primitives, by design.

Web applications vulnerable to shell-code injection... this sounds like a security nightmare.

They don't have to be global state - they can be updating thread local state, for example, in what is essentially dynamic scope. Depending on the OS, the efficiency of such TLS accesses can be quite good - on Linux, for example, it's just an extra pointer indirect or two with a segment selector (assuming the code is statically linked; it's very slightly more expensive in a solib).

Touche. It's still an API design that's going to prove problematic, though.

You're only a couple function pointers away from the syntactic sugar of the -> operator.

Yeah that's what I get for being in the OOP world for the daily grind. I think a C API is still definitely for the best. Perhaps a nice shortcut API for this would be something like:

    response_complete(200, body, response_header("Content-Type", "text/html"));

Well yes it should have been

    response_set_status(handle, 200);

My point was that the syntax in the example was C++.

in correct functional style shouldn't it rather be :

response_set_status(response, 200);

no issues with global state, threading (if correctly mutexed), etc...

All the pieces to do the whole framework are already in POCO and other libraries, with ssl and cookies etc.

http://pocoproject.org/docs/Poco.Net.HTTPResponse.html

http://pocoproject.org/docs/Poco.Net.html

Doing this in C seems silly to me.