Just noticed that in Perl the behavior is slightly different: http://perldoc.perl.org/functions/fork.html unsuccessful fork() returns undef, effectively stopping you from kill-ing what you don't want to kill.
When I read this article I thought it was preaching to a choir. I'm actually quite surprised people programming C don't check for errors. That's the only way the functions can provide a feedback.
fork() returns pid_t type which is usually mapped to int32_t. For this type there's no equivalent of Perl's "undef", the -1 is standardized as an error in all system calls that return an integer.
As for the argument why not send -2 instead, well guess what? Other negative values also have a meaning. Negative values in kill send signal to a process group instead of a process.
It's not libc responsibility to predict all possible things the programmer can do. Also unlike perl, C doesn't have exceptions so it can't exactly quickly terminate on error showing what went wrong.
Imagine C throwing SIGSEGV every single time a function failed.
That's the problem there. Kill takes an argument that's either a process id or a magic number or a different magic number or.... Those should be different functions, and the special cases like "kill all processes", "kill all processes in this group",... should be some kind of enumeration type. But it's C, so...
Returning undef has the advantage of being something completely useless as a process ID for any other function call.
$ perl -we 'kill 9, undef'
Can't kill a non-numeric process ID at -e line 1.
http://c-faq.com/null/ptrtest.html
For practical purposes, the null pointer and the integer `0` are one and same.
For most practical purposes, which is why I said that it wasn't a terrible approximation. However, they can be distinguished on some architectures:
intptr_t x = 0;
void *p = 0;
x == *(intptr_t*)(char*)&p;
assert(NULL == (void *)0);
int x = 0;
assert(NULL == (void *)x);