Sort of. It does some of the validation/auth code in the sshd parent daemon.

It has to: if it did 100% of the post-accept(2) work in a subprocess it would be pretty easy to remotely forkbomb/PID-exhaust a system by spamming invalid logins.

> You cannot avoid "I forgot to check for an error"

Yes you can. Checked exceptions and tagged unions both force calling code to be written with error-awareness.

In SSH's case, "I forgot to check" might lead to crashes (which might knock over sshd so new connections are impossible), or it might lead to false-positives via comparing NULL == NULL.

I'd much rather that boneheaded API users have to write code like

    resultstruct x = authenticate_user(user)
    if x.haserror {
        rv = { .user = user, .result = "successfully authenticated" } 
    } else {
        rv = { .user = user, .result = x.result }
    }
    return rv

At least that way some keystrokes are required to do the stupid thing. People still will (https://www.schneier.com/blog/archives/2008/05/random_number...), but the harder we can make it, the better.

How do you handle out of stack space on 'authenticate_user'? What about the machine check exception loading the DRAM page that contains "successfully authenticated"?

Dealer’s choice. Reallocating stack return values (ideally with compiler support) and aborting on stack overflow isn’t a bad combination, since you get decent guarantees about whether a function has enough memory to run until either completion or the next function call. POSIX’s out-of-stack-space behavior isn’t terrible here either.

As for DRAM: if by “exception loading page” you mean an OOM, then have malloc use the same error reporting system. If you instead mean “some other failure faulting/fetching a page from main memory”, well … crash? I don’t know of any platform that has semantics for handling that condition. Hardened spacecraft OSes, maybe?