Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

fork() can fail

rachelbythebay.com

Post reply on HN
Print view View original

91–100 of 320 posts

Re: fork() can fail

#91

Post by AnimalMuppet »

Somewhat OT, but in the same neighborhood:

Standard file handles are another thing you should not assume are there (though I'm not sure how to test for it programmatically).

We once had a user that, for whatever reason, tweaked their Unix installations to not pass an open stderr to processes - they just got stdin and stdout (that is, file handles 0 and 1, but not 2). If you wrote to stderr anywhere in your program, it wrote to whatever was open on handle 2, which was not a stderr that the OS passed in.

Yeah, that's a pretty insane thing to do, but somebody was doing it...

Re: fork() can fail

#92

Post by djcapelis »

yokom wrote: post #79

I don't use fork() that often, but my own paranoia is why I always test for if len(some_list) But it's just my way of covering my ass in case the laws of physics change during execution, or just in case weird bugs exist like those found in this article.

Careful, in many cases C will happily automatically and silently coerce unsigned values to signed values for your check if the types differ. Some functions may be actually intentionally returning numbers that large indicating success and your program might be invoking error handling code assuming a failure.

There's no good substitute for reading the RETURN VALUE(S) section the manpage for every function and testing appropriately.

Re: fork() can fail

#93

Post by cperciva »

rosser wrote: post #87
cperciva wrote: post #16

Earlier quoted context omitted.

I usually use switch with fork: if (daemon && !test_mode) { int pid; switch (pid = fork()) { case -1: /* Error */ fatal_error("Failed to fork"); case 0: /* In child */ break; default: /* In parent */ write_pid(pid_file, pid, !test_mode); exit(0); } } else { write_pid(pid_file, getpid(), !test_mode); }

I'm kinda surprised that the assignment-during-test thing doesn't generate a warning in the case of a switch statement. It does in other cases (if and while do under gcc and clang, at least).

If it creates warnings, you can silence them by adding extra parentheses, e.g.,

    if ((buf = malloc(buflen)) == NULL)
        goto outofmemory;

Re: fork() can fail

#94

Post by sdegutis »

dllthomas wrote: post #83
epochwolf wrote: post #71

Earlier quoted context omitted.

In C, there is no concept of null or undefined, only 0.

That's not quite true, but not a terrible approximation.

How is it not true? Besides void expressions (which aren't values) the above poster's statement appears correct.

Re: fork() can fail

#95

Post by cperciva »

Alupis wrote: post #57
cperciva wrote: post #7

This reminds me of one of the most epic bugs I've ever run into: mkdir("/foo", 0700); chdir("/foo"); recursively_delete_everything_in_current_directory(); Running as root, this usually worked fine: It would create a directory, move into it, and clean out any garbage left behind by a previous run before doing anything new. Running as non-root, the mkdir failed, the chdir failed, and it started eating my home directory…

Could you have not just checked to see if you actually created the directory and/or check to make sure you moved into the directory before proceeding with your destructive function? (Defensive Programming 101 really).

There's lots of things they could have done. As I said elsewhere, this wasn't my code,

Re: fork() can fail

#96

Post by dllthomas »

kelnos wrote: post #81
yokom wrote: post #79

I don't use fork() that often, but my own paranoia is why I always test for if len(some_list) But it's just my way of covering my ass in case the laws of physics change during execution, or just in case weird bugs exist like those found in this article.

Perhaps I'm misunderstanding what you're saying, but that's wrong too. With fork() you need to always test 3 cases: * -1: error * 0: success, in child * > 0: success, in parent Testing for <= 0 would cause you to think there's an error when you're really just the child process.

Or that you're the child process when really there's an error, which might go undetected longer.

Re: fork() can fail

#97

Post by rosser »

cperciva wrote: post #93
rosser wrote: post #87

Earlier quoted context omitted.

I'm kinda surprised that the assignment-during-test thing doesn't generate a warning in the case of a switch statement. It does in other cases (if and while do under gcc and clang, at least).

If it creates warnings, you can silence them by adding extra parentheses, e.g., if ((buf = malloc(buflen)) == NULL) goto outofmemory;

I was originally going to comment saying exactly that — under gcc and clang, at least, just the extra parens will disable the warning; no comparison necessary — but thought to test that the warning is generated in case of a switch statement (and is then disabled by the extra set of parens), which led to realizing the behavior is different.

Just surprised by the inconsistency.

Re: fork() can fail

#98

Post by comex »

jimm wrote: post #85
TheLoneWolfling wrote: post #59

Earlier quoted context omitted.

while(1) {fork()}; is "better", as the version you mention will quit as soon as it is able to fork a new process.

Will it quit? A failed fork() will return -1, which is non-zero thus true in a boolean context. The while(fork()) {...} will run.

But it will stop when fork returns 0, i.e. in the child processes, making it non-exponential.

Re: fork() can fail

#100

Post by dllthomas »

sdegutis wrote: post #94
dllthomas wrote: post #83

Earlier quoted context omitted.

That's not quite true, but not a terrible approximation.

How is it not true? Besides void expressions (which aren't values) the above poster's statement appears correct.

A null pointer does not need to have an all-zero representation, which mattered once on some architectures. I'm not aware of any current architecture that does it that way, but that's still what the standard says, which is to say that C does technically have a notion of null which is not necessarily identical with 0.

http://c-faq.com/null/machexamp.html

Post reply on HN