Time To Get Rid Of errno

Posted Aug 21, 2015 22:04 UTC (Fri) by kleptog (subscriber, #1183)
In reply to: Time To Get Rid Of errno by wahern
Parent article: Glibc wrappers for (nearly all) Linux system calls

> That kernels still only return a single integer value is more about not evolving with the times.

Well, and the fact that you can't just change the userland/kernel interface like that. Promises have been made about what happens to all the registers and there isn't anywhere to put any extra return values in a backward compatible way.

On top of that, even if the kernel could return the info, you can't change the POSIX API either so errno is here to stay.

Time To Get Rid Of errno

Posted Aug 21, 2015 23:23 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

Unless you simply skip libc and start calling the syscalls directly, like Go does.

Time To Get Rid Of errno

Posted Aug 22, 2015 9:06 UTC (Sat) by kleptog (subscriber, #1183) [Link] (2 responses)

Ofcourse, if a language wants to skip libc then they can. That just reinforces the fact that the syscall interface can never be changed to return more information.

FWIW I disagree with the OP, it is nice to be able to know that a syscall either succeeded or failed and not some halfway state. If you did a write and the write was short the write still succeeded. POSIX does specify that if the write size is less than PIPE_BUF length then it will succeed or fail atomically. If you have to write your code to handle the case where some data was written but you also have to handle an error code, that just feels more fragile.

All the cases where it would be useful to return more information the specific syscall has made allowances for it, for example recvmsg(). The fact that there are syscalls that are badly designed is a problem with the interface and not the mechanism. I find the ip/tc tools use of netlink here pretty bad, they return EINVAL and you have to hope there's something useful in the kernel log. Would it have killed them to add an extra field for "extended error code"?

Time To Get Rid Of errno

Posted Aug 23, 2015 8:03 UTC (Sun) by lsl (subscriber, #86508) [Link] (1 responses)

> POSIX does specify that if the write size is less than PIPE_BUF length then it will succeed or fail atomically.

Only when actually writing to a pipe, not in the general case.

I just discovered that Linux (since 3.4) implements a Plan-9-style pipe mode where reads from a pipe match up with previous writes (provided the latter weren't greater than PIPE_BUF bytes). See the pipe(2) Linux manpage for the O_DIRECT flag to pipe2. Very nice.

Time To Get Rid Of errno

Posted Aug 23, 2015 10:35 UTC (Sun) by kleptog (subscriber, #1183) [Link]

> I just discovered that Linux (since 3.4) implements a Plan-9-style pipe mode where reads from a pipe match up with previous writes (provided the latter weren't greater than PIPE_BUF bytes). See the pipe(2) Linux manpage for the O_DIRECT flag to pipe2. Very nice.

How is this different to socketpair(AF_UNIX, SOCK_DGRAM) ? The only reason I can think of is that you want it to work on systems without UNIX domain sockets...

Time To Get Rid Of errno

Posted Aug 22, 2015 2:58 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

I'm looking forward to Mill and syscalls being a "portal" call (they act just like a function call and can return multiple values that way).