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

121–130 of 320 posts

Re: fork() can fail

#121

Post by M00n_Sl47r »

dllthomas wrote: post #70
Alupis wrote: post #65

Earlier quoted context omitted.

True -- I guess fork() has failed at that point. I was more getting at the article's authors scenarios of careless scripts treating -1 as a valid pid (which should always be > 0), which would be a failure of the script instead.

Well, it's a failure of the script and the POSIX API - it is unfortunate that a pid_t inhabited by -1 means "failure" in one case and "everything" in another. It is certainly not fork, narrowly, to blame.

I think the point that the author was making, outside of any criticism to the API itself, is that the hapless programmer may not know that fork() could even return -1. The article is pointing out that possibility as documented by the API, not criticizing a failure of the API. Whether or not the API is faulty in this--and I tend to agree with you--is outside of the scope of the article, though only just.

Re: fork() can fail

#122

Post by [deleted] »

loup-vaillant wrote: post #118
cperciva wrote: post #93

Earlier quoted context omitted.

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

Careful with that example. The parentheses here don't just remove the warning. They remove a bug . This code: if (buf = malloc(buflen) == NULL) goto outofmemory; is actually equivalent to that code: if (buf = (malloc(buflen) == NULL)) goto outofmemory; So, malloc gives you a pointer, which is compared to the null pointer, giving you either 0 or 1. And that is assigned to buf. Hopefully your compiler will warn you abo…

[deleted]

Re: fork() can fail

#123

Post by cperciva »

loup-vaillant wrote: post #118
cperciva wrote: post #93

Earlier quoted context omitted.

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

Careful with that example. The parentheses here don't just remove the warning. They remove a bug . This code: if (buf = malloc(buflen) == NULL) goto outofmemory; is actually equivalent to that code: if (buf = (malloc(buflen) == NULL)) goto outofmemory; So, malloc gives you a pointer, which is compared to the null pointer, giving you either 0 or 1. And that is assigned to buf. Hopefully your compiler will warn you abo…

Oops, quite right. I was originally thinking of

    if ((rc = pthread_mutex_lock(mtx)))
        err("mutex_lock failed: %s", strerror(rc));
but decided to switch to a better-known function at the last minute and completely lost the point.

Re: fork() can fail

#124

Post by yosefk »

Alupis wrote: post #51
swah wrote: post #29

Earlier quoted context omitted.

In those times I wish I could use the emacs lisp way: (let (dir "/foo") (create-directory dir) (with-current-directory dir (delete-all-files-recursively))) Factor recognized the value of dynamically scoped variables: http://concatenative.org/wiki/view/Factor/FAQ/What's%20Facto... A lot of code became much simpler because of that decision.

This isn't really fork() failing per se -- but rather a failed program/script that did not understand the well defined and clearly documented behavior of fork().

Taking the square root of a negative number removing all the files in your home directory could be "well defined and clearly documented behavior". Would you blame the API author at that point or would it still be strictly your fault?

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.

Re: fork() can fail

#125

Post by Macha »

kazinator wrote: post #34

I once did rm -rf $PREFIX/usr/lib in a Bash script being run as root. PREFIX was misspelled, and set -u was not in effect, so the misspelled variable silently expanded to nothing ...

Or Bumblebee's pretty infamous by now:

    rm -rf /usr /lib/bumblebee

Re: fork() can fail

#126

Post by cperciva »

loup-vaillant wrote: post #120
AnimalMuppet wrote: post #78

Earlier quoted context omitted.

Not after exit(0) returns, no. Instead, you're going to want it after some programmer removes exit(0) six months from now.

I'm going to write a pre-processor which adds the appropriate `break` statements automatically. No more fall-through bug. (And if you really want to fall through, I could add a `fallthrough` keyword.)

For what it's worth, it's a style bug in FreeBSD to have a fallthrough which does not have a /* FALLTHROUGH */ comment.

Re: fork() can fail

#127

Post by loup-vaillant »

spc476 wrote: post #107
dllthomas wrote: post #100

Earlier quoted context omitted.

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

But in C, a 0 in a pointer context is always considered the NULL pointer (even if the physical value of a NULL pointer isn't all zeros).

Additionally in a boolean context a null pointer is indistinguishable from "false" (meaning, zero).

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

For practical purposes, the null pointer and the integer `0` are one and same.

Re: fork() can fail

#128

Post by cperciva »

spc476 wrote: post #107
dllthomas wrote: post #100

Earlier quoted context omitted.

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

But in C, a 0 in a pointer context is always considered the NULL pointer (even if the physical value of a NULL pointer isn't all zeros).

Only a compile-time constant zero. So

    assert(NULL == (void *)0);
is fine, but

    int x = 0;
    assert(NULL == (void *)x);
is not.

Re: fork() can fail

#130

Post by _yosefk »

takeda wrote: post #101
mutation wrote: post #18

Just noticed that in Perl the behavior is slightly different: http://perldoc.perl.org/functions/fork.html unsuccessful fork() returns undef, effectively stopping you from kill-ing what you don't want to kill.

Similarly python throws an exception, and I bet other languages have their own behaviors, but in case of C this is the only way (or at least it is the only non complicated way to do it). When I read this article I thought it was preaching to a choir. I'm actually quite surprised people programming C don't check for errors. That's the only way the functions can provide a feedback.

Nothing in C forces the API designer to use -1 as "bad PID" in one place and as "the set of all PIDs" in another, however. Perl's undef isn't that different from returning, gosh, -2 or any other bloody number except -1 in C.
Post reply on HN