Hacker News Reader

Comment by bluejekyll | Hacker News Reader

This is why separating return values from error codes is important.

For example, in Rust, you’d never get into this situation, because a decent fork ffi function would immediately convert -1 into a Result carrying an error, and properly check errno. Java and C++ would throw an exception, etc.

Thus preventing all sorts of bad behavior up the stack.

View on HN

I cannot upvote this enough. I've written some rust code which uses fork, and after reading this, I went to check the docs. And lo and behold it follows the convention you put forth. So I was safe.

Yay Rust, where things either fail (panic and quits the program) or returns a result that you can't use until you check for the error.

> So I was safe.

Fork (without exec) is a very sharp tool because it can violate ownership, doubly so in multi-threaded programs. So just because you get a Result from it doesn't mean all its pitfalls are handled.

It’s true, though the FD_CLOEXEC flag generally helps in this area.

Recently though I had to remove a bunch of these safeguards because I wanted to share handles and such across processes. So sometimes it’s nice to have that feature.

Correct me if I'm wrong, but isn't there a problem with mutex sharing as well?

I was using a wide definition of "ownership". Parent and child unintentionally sharing a mutex is one manifestation of those issues.

Note that posix says you shouldn't do anything except immediately call exec after fork in multithreaded programs.

This is not true. IIRC, you can do anything as long as you don’t call any function which is not async signal safe. Otherwise, it would be very difficult to do simple things like run a child process in a separate directory (with chdir()), or report a failed exec() to the parent.

The typical way to report errors upwards is to create a pipe with CLOEXEC and then write the error code to it from the child if exec fails. This requires at least calling write().

You may be remembering vfork(), which is a bit of an obsolete API.

Ah, yes, I overstated the case. Thanks for clarifying the rule is only signal safe functions. Notably, this excludes malloc, etc. (I was thinking as I posted I should dig up the relevant quote just to be sure. Oops.)

System calls actually do return the result seperately from success or failure. It's libc that smooshes them into one thing.

Specifics vary by platform, but for FreeBSD i386, the result usually comes back in register EAX (but docs say sometimes another register), and the success or failure comes back as the carry flag. Of course, C never made access to the carry flag easy, so libc smooshes things together.

System calls can return them separately, but don’t have to. On Linux a failing syscall returns -errno; the syscall wrapper assumes any return value in the range -1 to -4095 is an error, stashes the positive error number in the C errno variable and translates the return value to -1.

posix_spawn() is reasonably portable and returns them separately.

It’s also not a system call :-/ at least with Linux/glibc. Although this is not really the point of the discussion, I’m not aware of system calls that return their result separately the way that posix_spawn does. They obviously could.

I was comparing to fork() setting the errno global.

Modern errno is a macro that designates a thread-specific location.

What posix_spawn does is something like this:

    posix_spawn() {
        ...
        pid_t pid = fork();
        if (pid == 0) {
            ...
        } else if (pid > 0) {
            ...
            if (...) {
                ...
                return ernno_from_child;
            }
            ...
        } else {
            return errno;
        }
        ...
    }

I’m just pointing out that you’re still using errno, you’ve just hidden it behind a function. All of your syscalls are still getting their results stored in errno. It’s just fork() / exec() with some extra sauce, not a syscall in itself.

I’m not trying to argue, I’m just pointing out that this is just a wrapper function on Linux anyway, and if you want to find an example of a different way to report errors from the kernel, it’s not posix_spawn().

Posix_spawn on Linux uses the clone() system call, and passes a pointer called args. Errors come back at args.err

posix_spawn() actually uses fork() internally, not clone(), as far as that distinction is possible to make. Both fork() and clone() are implemented with the same kernel entry point, which is called "clone".

Here is the relevant line in glibc:

https://github.com/bminor/glibc/blob/b5b7fb76e15c0db545aa11a...

Errors are returned as the function return value.

https://github.com/bminor/glibc/blob/master/sysdeps/unix/sys...

"The Linux implementation of posix_spawn{p} uses the clone syscall directly with CLONE_VM and CLONE_VFORK flags..."

Though you're right about errno, line 305.

All that is certainly true, but we're talking about a function that dates back to the 70s here. It predates all of those nice error handling concepts (exceptions, Result<T>, multiple return values), so it's pretty sensible from that perspective to have -1 be the error value.

But yes, don't do this today, obviously.

I wonder how a rust compiler implementation would fare on a PDP-11/20

They do have easily accessible PSW so using, say, a carry flag to implement Option<i16>/Result<i16, i16> is a possibility.

I don't think it's possible to fit even the type inference in 64k.

We're still dealing with this today as so many of us deploy and develop software for POSIX that exposes us to these edge cases.

So, yes, while working in Rust and using better APIs designed around these interfaces, we won't do the wrong thing, but there's still a lot of people that are going to end up getting cut by these old 70's interfaces. It would be nice if we didn't have to work with these, but many of us still do.

> All that is certainly true, but we're talking about a function that dates back to the 70s here. It predates all of those nice error handling concepts (exceptions, Result<T>, multiple return values), so it's pretty sensible from that perspective to have -1 be the error value.

It doesn't predate creating a struct which tells you exactly whether thing went wrong and how.

It predates C functions being able to return a struct.

In fact, it predates C itself. See https://github.com/DoctorWkt/pdp7-unix/blob/9947fbf42bbb3c94...

Yeah, but in C++ you get people ignoring exceptions too. I'm fine with return codes, I don't mind them even though exceptions are maybe a little bit better.

True, but in this case, ignoring an exception would be better than ignoring a return code, right? It prevent you from accidentally sending a signal to -1 (e.g. all the processes you can). The danger here with the return code is that the return code value is a valid (but not intended) input to another function that normally uses the normal return value.

True, I guess just this example didn't jive with me. I'd never dream of ignoring the return code of fork().

Some other call I don't respect enough would probably bite my ass, though.

It's not just a question of whether you did the right thing when you wrote the code. Code gets refactored and moved around, maybe by people less experienced than the original author, or maybe just by the original author when they're tired or after they've forgotten the context. Wrapper functions get defined, libraries get updated, and support gets added for new platforms. Each of those changes is an opportunity to accidentally stop checking the return code.

Hence why `Result` is really valuable. Can't ignore it (plus, the semantics are straightforward)

If by ignoring, you mean non catching anything, I'm often okay with that. If an exception makes it top-level, you'll get a std::terminate and be done.

The "canonical" example people use a lot is std::bad_alloc. Often, there is no point in catching it -- what cleanup or fallback work are you planning to do when you can't even allocate memory?

Of course, silently swallowing exceptions with an empty catch-block is terrible.

If you ignore (as in fail to handle) an exception, your software dies safely, it won't do the wrong thing.

If you ignore or misuse error code, you carry on in a corrupted state.

Have you seen old java code that has tons of empty try / catch blocks? It is very, very common.

Java is special in this regard because the common case of letting an exception terminate the program is harder than ignoring it. When I was still writing Java, I'd gotten so annoyed by this that in the top layers every method "throws Exception". It was less verbose than promoting all the checked exceptions to runtime errors.

Unfortunately people don't know about this possibility and write empty catch statements because "it's not going to happen anyway". Yeah right.

> Yeah, but in C++ you get people ignoring exceptions too

... and then you can just do `coredumpctl gdb` and start debugging right where things went wrong ?

A similar "sigil" related bug was the cause of the sudo exploit a few weeks back. Option types are often sold as a way to end the dreaded 'null pointer exception' but I think ending the dreaded "sigil we forgot to handle" benefit may be bigger.

Wouldn't wrapping potentially dangerous function calls as monads in C++ solve this exact issue?

Go also cleanly separates results and errors. syscall.ForkExec returns an error if the call failed.

Yes it's just a good practice when exposing an API. It's language agnostic.

> For example, in Rust, you’d never get into this situation

… because you cannot fork() safely in Rust.

Using integer codes like 0 and -1 were the old style of returning errors. Often combined with some undocumented features.

It is really wrong, but that is caused by the C-functions returning only one integer of data. And the bad C libraries. Null used to be -1 in some compilers. Mixing pointers as integers is a recipe for disaster, not compatible with some CPU-s, but it is C-standard.

In the windows32 API they improved it a bit, with functions that only returned an Error code. They required struct addresses in which results were placed. I think that the process structure is also a lot better than the fork() function.

It's even more fun when you're mixing libraries, and some of them return 1 on success, some of them return zero, and some -1, and you can't tell by inspection which is which.

Bonus points if the API you're using inconsistently mixes boolean, null-pointer, HRESULT, DWORD, and returning a status in a value you pass a pointer to (you did initialize that value, right?)

Why do we keep doing this to ourselves?

I don't know Rust well, but my understanding is the Rust way is better than Java or C++.

Exceptions are a mess. Either you go the Java route of tagging everything as throwing every subclass of Exception under the sun (which encourages people to write empty catch blocks to silence a noisy compiler), or you go the C++ route where you are not totally clear an error can occur when writing the code or from glancing at it. (Combine with operator overloading for most confusing results.)

Having an error result that can perhaps be easily propagated to the caller is the best of both worlds, and I think is the thing that good C code tries to approximate in a more manual way.

What are you talking about? They are perfectly separated. Top bit of the result IS the separation.

And do you know why you'd never get into his with rust? Because rust doesn't support fork.

> What are you talking about? They are perfectly separated. Top bit of the result IS the separation.

"Separation" in this case implying "hard to misuse", which the POSIX fork() API certainly is not.

> And do you know why you'd never get into his with rust? Because rust doesn't support fork.

Yes, it does. https://docs.rs/nix/0.17.0/nix/unistd/fn.fork.html

Reply on news.ycombinator.com