Ghosts of Unix past, part 3: returning -1 for system call failure [LWN.net]

Ghosts of Unix past, part 3: returning -1 for system call failure

Posted Nov 16, 2010 21:21 UTC (Tue) by jhhaller (subscriber, #56103)
Parent article: Ghosts of Unix past, part 3: Unfixable designs

One of the other problems resulting from early Unix implementation is the return code of -1 for failed system calls, with errno set as a side affect. If I remember correctly, this was a side effect of the PDP-11 instruction set, with the actual interface being a condition code and a single register return. If the condition code was set, the return register was errno, otherwise, it was the return value of the system call. Because of the limited data on the function return, it was impossible to give partial results when a system call failed. This has led to such things as failed writes not being able to report how many bytes were written before the failure, as well as the signal/select/poll problems described in the article. While the condition code was a good idea allowing fast failure checking, the translation into the C library interface and the single return code was a problem.

(Log in to post comments)

Ghosts of Unix past, part 3: returning -1 for system call failure

Posted Nov 19, 2010 23:48 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

I don't know if it was an accident due to PDP-11 praticality or just good design philosophy, but I very much appreciate the convention in Unix of not returning information when a system call fails. I.e. a failure is a failure. If you get back useful information, or the system changes state, it's not a failure, but a different kind of success.

So I guess you're saying if a read of 10 sectors fails due to a media error on the 5th sector, you'd like to see the result, "failed due to media error, but read the first 4 sectors." I like Unix'es version much better: Instead of requesting 10 sectors, you request "up to 10 sectors" and it succeeds with "4 sectors read" and the next read truly fails.

Things that fail but don't fail are much harder to program to. They engender mistakes and convoluted code. "Failure" has the special implication that you can probably just stop thinking about it and give up on whatever you were doing. They are the inspiration for exception throwing in programming languages.