[paraboul]

Looking 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.

[joliv]

Why do you think it's called "nope.c?" ;)

[idlewan]

Yes, it uses lots of strcpy and sprintf instead of strncpy, snprintf or strlcpy. It's bound to be exploited.

[meowface]

Not only just that, but it seems in many cases there is absolutely no bounds checking whatsoever. There are legacy libraries out there that use the str* group of functions safely, because there is careful bounds checking before each call. That's still far less reassuring than just using safe functions, but it's better than absolutely nothing.

Based on the inconsistent use of tabs and spaces, lack of whitespace around any sort of operators or special syntax, and total disregard for security, this looks much more like a 1995 project than a 2014 one.

[eq-]

It depends. It's not like there's no safe way of using strcpy and sprintf.

[pconner]

The safe way to use strcpy is to use strncpy

[abadcafe]

no，strncpy is worse than strcpy，the right way is strlcpy.

[gandalf013]

http://benpfaff.org/writings/clc/strncpy.html

[pjmlp]

That is what happens when language designers decide to throw away design decisions from Algol.

[asveikau]

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.

[pjmlp]

I was speaking about unsafe by design.

Sockets are library/OS responsibility.

[asveikau]

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.

[pjmlp]

It is, because crashing is a better alternative than wounding the process and keeping on running producing bad results, or corrupting memory state and crashing anyway on a total unrelated part of the application.

[yaph]

Apparently people are taking advantage of that right now...