$ mkdir /tmp/foo && cd /tmp/foo && touch bar.txt

This style is pretty prevalent when writing test cases in shell (or just shell scripts in general), e.g. when using something like sharness[1].

[1] https://github.com/mlafeldt/sharness

http://www.gnu.org/software/bash/manual/bashref.html#index-s...

https://news.ycombinator.com/item?id=8054440

    $ mkdir -m 0700

So if fork is behaving as documented, returning -1 is because of "fork failing".

At what point do API authors share the blame for a needlessly harsh punishment delivered upon a predictably common error?

I certainly prefer to work with systems produced by people tending to think it'd be their fault more often than not.

It's just as wrong to feed kill() -1 as it would be to feed it -48585 or "babdkd" (unless that is explicitly your intention). A simple sanity check of if [ "${pid} > "0" ]; is all that's necessary to protect against this behavior.

So, I would argue, the fault lays on the users, not the creator, for not understanding the API when all materials necessary to understand said API are freely available.

(with that said, I think it's safe to say, we've all been bitten by not fully understanding some function before)

This kind of mistake is godawful and should not be defended. (but it's correctly fixed through stronger typing, not through choosing -48585 as the code for killing everything).

You're arguing that people should read the API before doing anything with it. Parent's point is that this class of error can be avoided by strong typing (eg, via algebraic datatypes), negating the chance that it would happen in the first place. Which, I think, is the right way to look at the problem. But certainly, if you do have to use a weakly-typed, unsafe language which does not provide this kind of guarantee, be sure to read the documentation twice.

Which doesn't mean you won't get bitten when it turns out that the person writing a library you rely didn't RTFM.

Is there a reason fork can't be changed to just crash the program on failure? Are situations where a program usefully does something other than crash on fork failure, more or less common than situations where a program fails in the way described in the article?

If you were forking in a high-level language such as Python, failing to fork would raise an exception which would possibly crash the program if left unhandled.

C does not have exceptions so return codes are used to indicate success or failure. This is true for nearly every function, not just fork. If you're not checking for errors in a C program, it's going to break in unexpected ways, and will possibly be vulnerable to exploitation.

fork has 3 possible return values: - 0 for the child process - a positive number for the parent process - a negative number if it failed.

If you look at the man page's "Return Value" section, it is extremely clear, see: http://linux.die.net/man/2/fork

"On success, the PID of the child process is returned in the parent, and 0 is returned in the child. On failure, -1 is returned in the parent, no child process is created, and errno is set appropriately."

YES. Situation: fork bomb, can't create new processes. How do you notice? Typically because you can't spawn new processes from your shell because fork is failing. With bash, there is a kill builtin - so you have a chance of cleaning things up (depending) if you have a shell open. If the failed fork kills the shell, then oops, you don't have a shell open.

Specifically, the code you wrote would behave the same if `dir` had lexical scope.

The scoping of the dir variable itself is irrelevant.

What the person meant when he wrote, "In those times I wish I could use the emacs lisp way," is, "In those times I wish I could use a lisp _macro_" -- particularly, one of those macros that makes a change, runs some code ("the body") then undoes the change.

Since all lisps have macros, the code above would work in any lisp -- not just Emacs Lisp. Among lisps, Emacs Lisp is famous for its dynamically scoped variables. Consequently, the specific reference to Emacs Lisp perpetuates the confusion that how variables are scoped has anything to do with what we have been talking about.

    with-auto-compression-mode  with-case-table
    with-category-table         with-coding-priority
    with-current-buffer         with-decoded-time-value
    with-demoted-errors         with-electric-help
    with-help-window            with-local-quit
    with-no-warnings            with-output-to-string
    with-output-to-temp-buffer  with-selected-frame
    with-selected-window        with-silent-modifications
    with-syntax-table           with-temp-buffer
    with-temp-buffer-window     with-temp-file
    with-temp-message           with-timeout
    with-timeout-suspend        with-timeout-unsuspend
    with-wrapper-hook

    char *dir = "/foo";
    mkdir(dir, 0700);
    if (chdir(dir) == 0)
        delete_all_files();

with-temp-buffer is another example: a macro that bridges the functions for "string manipulation" and the ones for "buffer manipulation", since you start writing stuff this way:

  (defun replace-in-string (str from to) 
    (with-temp-buffer
      (insert str)
      (beginning-of-file)
      ;;; Here you can use all your normal text editing commands
      (replace-regexp from to nil t)         
      (buffer-string)))

    char *olddir = getcwd();
    chdir(newdir);
    try {
        do_stuff();
    } finally {
        chdir(olddir);
    }

Also, getcwd has a size parameter these days, and of course you want to check if the getcwd actually worked.