First link on the documentation page is:
Build a simple app using node.c
node? Typo?
Nope.c – A web framework with a tiny footprint
41–50 of 53 posts
Re: Nope.c – A web framework with a tiny footprint
#42This site feels ridiculously fast. I've noticed that with other compiled frameworks too, e.g. CppCMS: http://cppcms.com/wikipp/en/page/main I wonder if it is just the lightweight HTML the websites use, or if there is really so much speed to gain from using a compiled language.
It is the speed of using a language with a compiler.
Re: Nope.c – A web framework with a tiny footprint
#43Looking at the source code : https://github.com/riolet/nope.c/blob/c883b11df78bb8115d5e51... It tries to copy a buffer of 1024 byte (max) into a buffer of 512 bytes (by executing a request with an URL longer than 512 bytes). It also runs 15 children process and use blocking socket, meaning that it's easily "DoS'able". The overall code seems very "unsecure" and poorly designed.
That is what happens when language designers decide to throw away design decisions from Algol.
Re: Nope.c – A web framework with a tiny footprint
#44First link on the documentation page is: Build a simple app using node.c node? Typo?
Could be a typo, or a freudian slip.
Re: Nope.c – A web framework with a tiny footprint
#45Looking at the source code : https://github.com/riolet/nope.c/blob/c883b11df78bb8115d5e51... It tries to copy a buffer of 1024 byte (max) into a buffer of 512 bytes (by executing a request with an URL longer than 512 bytes). It also runs 15 children process and use blocking socket, meaning that it's easily "DoS'able". The overall code seems very "unsecure" and poorly designed.
That is what happens when language designers decide to throw away design decisions from Algol.
Right, because Algol had non-blocking sockets.
Some of these mistakes transcend the language. Unfamiliarity is one thing but I don't believe you can take someone who writes C code like this and they'll instantly do a stellar job in some other language.
Re: Nope.c – A web framework with a tiny footprint
#46Earlier quoted context omitted.
It depends. It's not like there's no safe way of using strcpy and sprintf.
The safe way to use strcpy is to use strncpy
Re: Nope.c – A web framework with a tiny footprint
#47Why wouldn't one write something like that directly as an httpd or nginx module? You get fastest possible C http server, together with a very good utility library and just need to write your own routing and handling functions. I mean, why rewrite the server component when you can just use an existing one? I can see not wanting to use one of the CGI interfaces for maximum performance (and ultimate fun), but there's very little point in rewriting the http(s) handling yet again.
Re: Nope.c – A web framework with a tiny footprint
#48Earlier quoted context omitted.
That is what happens when language designers decide to throw away design decisions from Algol.
Right, because Algol had non-blocking sockets. Some of these mistakes transcend the language. Unfamiliarity is one thing but I don't believe you can take someone who writes C code like this and they'll instantly do a stellar job in some other language.
I was speaking about unsafe by design.
Sockets are library/OS responsibility.
Re: Nope.c – A web framework with a tiny footprint
#49Poorly coded, no standards, also is vulnerable to DOS and memory leaks...
Re: Nope.c – A web framework with a tiny footprint
#50Earlier quoted context omitted.
Right, because Algol had non-blocking sockets. Some of these mistakes transcend the language. Unfamiliarity is one thing but I don't believe you can take someone who writes C code like this and they'll instantly do a stellar job in some other language.
I was speaking about unsafe by design. Sockets are library/OS responsibility.
I believe you missed my point, though. I will grant you that many libc functions do not follow what are currently considered best practices.
But you can't take the textbook example of what not to do and say that this is representative of everyone who works in the language. Just as I can't take an example of extremely bad code in some high-level language, which naively goes against what is considered sane practice, and say it's the language's fault.
Put alternatively, in many contexts an out of bounds exception is almost as bad as the trouble you can get into with pointers. [I say "almost", conceding the point that with the C you can do crap like clobber a return address on the stack.] Someone who simply doesn't give a shit about array bounds (like this author, it sounds like) is not likely to be totally saved (as if by magic) by a higher-level language.