On Thu, 2009-07-30 at 20:21 +0200, Remi Gacogne wrote:
Le jeudi 30 juillet 2009, Timo Sirainen a écrit :
What the hell were POSIX people thinking?? This is the first syscall I've seen that behaves like this, and apparently without any good reason! Wonder how many other new system calls there are like this, that I haven't noticed yet..
Looks like all posix_*() syscalls do that. Wonder if there are more.
Looks like too many people were incorrectly using errno, especially in multi- threaded context.
From http://www.unix.org/whitepapers/reentrant.html :
"In addition, all POSIX.1c functions avoid using errno and, instead, return the error number directly as the function return value, with a return value of zero indicating that no error was detected. This strategy is, in fact, being followed on a POSIX-wide basis for all new functions. "
But that doesn't solve anything, because old functions' API can't be changed. The only thing this change did was to make it more difficult for programmers to remember how functions' error handling should be done. In both APIs the success is indicated by returning 0, which makes it especially difficult to notice when it's being used wrong.
If they really had to change this, it would have been much better to both set errno and return -error, that way it would have allowed also 2/3 of the old style error checks:
if (posix_fallocate(..) < 0) perror() // works if (posix_fallocate(..) != 0) perror() // works if (posix_fallocate(..) == -1) perror() // doesn't work
Now none of them work.
I did also a quick google code search for posix_fallocate and found several other programs that handle the error wrong. And I'm sure it's only going to grow.
Oh well, maybe some day gcc and libc add some features to catch at least the < 0 and == -1 usage (which would already work if posix_fallocate() had been specified to return unsigned int, not int).