errno or -errno or -1 or...WTF?!

http://man7.org/linux/man-pages/man2/syscalls.2.html

Note: system calls indicate a failure by returning a negative error number to the caller; when this happens, the wrapper function negates the returned error number (to make it positive), copies it to errno, and returns -1 to the caller of the wrapper.

So the system calls quite sensibly return a negative number to indicate an error, but then someone added code to be executed every single time a syscall is made just to check its return value and store that in a separate variable, turning all errors into -1? Now every time you use a syscall you have to check for errors and then pull the correct error number back out of errno instead of straightforwardly passing the error value through as the return value? Which brain-damaged idiot thought this was a good idea!?

>>1
sentinel values considered holy fuck it's 2015 already what are you even doing

errno is still useful but if ((errno = syscall()) < 1) goto HELL; sounds easy enough. Or how would you save it? You wouldn't?

Also some wrappers are there to make the kernel routines more like library calls. See http://git.musl-libc.org/cgit/musl/tree/src/unistd/write.c

That is pretty weird.
Why would anybody do that?

>>1
You can blame Ken Thompson (probably) for the way errno works. Linux returns the error code in a register (on most architectures, anyway) because it's faster and simpler than storing it in the caller's memory.

In all honesty though, this sort of trivial API translation is not even close to being the most expensive component of making a system call. Nothing stops you from bypassing the libc and exercising the kernel ABI directly if you really care that much.

>>5
hey terry davis

what do you shove up your nose to force a nose bleed

DOS has much saner error handling; on error, CF is setted(sic) and an error code is returned in AX. On success, CF is cleared (and AX might contain something useful, depending on the syscall.)

>>5
http://man.cat-v.org/unix-1st/2/sys-open

The error bit (c--bit) is set if the file does not exist [...]

Looks like Unix was the same as DOS from the beginning, so whoever wrote the C interface wrappers (I fucking hate that word...) screwed up. If you look at the Linux syscall code you'll see they do things like return -ENOENT; on the kernel side already. See http://lxr.free-electrons.com/source/fs/open.c#L1072

Instead of something like this (this is open()'s description):

Upon successful completion, these functions shall open the file and return a non-negative integer representing the lowest numbered unused file descriptor. Otherwise, these functions shall return -1 and set errno to indicate the error.

Why not

Upon successful completion, these functions shall open the file and return a non-negative integer representing the lowest numbered unused file descriptor. Otherwise, these functions shall return the negative value indicating the error code.

Incidentally, this is how the Anonix syscalls work... no errno shit except at the APRI layer which isn't needed for native API code.

>>7
dont worryy cudder no1s gonna take ur lunch money ur free to be whatever u want in life

>>7
DOS is no paragon of uniformity either. Any non-trivial program must interact with multiple ABIs (BIOS, real mode DOS, EMM, VCPI...) that all have their own unique calling convention. Worse, there is no standard HLL binding for any of these (even the HLL implementations themselves have unique ABIs of their own!) so you can't even use an abstraction layer to contain the madness.

contain my madness

contain my anus

Which brain-damaged idiot thought this was a good idea!?
System calls are generally not invoked directly, but rather via wrapper functions in glibc [...]

Surprising exactly no one. It's becoming increasingly harder to find something about glibc that isn't utter garbage.

>>12
The use of errno is specified by POSIX and reflects historical practice. There are lots of reasons to dislike glibc but this isn't one of them. Any other libc for Linux will do the same thing.

contain my madness in your anus

>>13
yeah that's why every time you people discussing standardizing on posix they no longer complain about the cost of the specification, but they do shoot it down pretty quick with comments about how it works miraculously well but it's fucking stupid at every turn.

>>15
I don't think most people even realize the POSIX spec isn't available for free, to be honest.

>>16
It is.
http://pubs.opengroup.org/onlinepubs/9699919799/

dubs.opengroup/onlinedubs/9699919799

>>13
Yes, everyone knows that ERRNO is part of POSIX, but is this silly wrapper and negation nonsense part of POSIX as well?

>>19
Yes.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html

Upon successful completion, these functions shall open the file and return a non-negative integer representing the lowest numbered unused file descriptor. Otherwise, these functions shall return -1 and set errno to indicate the error.

>>19
No

>>20
POSIX says nothing about system calls.

Bohemian 'em