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

301–310 of 320 posts

Re: fork() can fail

#301

Post by nitrogen »

azinman2 wrote: post #298
nitrogen wrote: post #210

Earlier quoted context omitted.

Conclusion: design for humans and default to non-fatal situations. It's a lot safer to fail fast and fail safe than to hobble along with possibly undefined state doing who knows what to the system and to the user's data.

You're missing my point. It's not about undefined state -- it's about sane defaults and APIs that make things that crashes/bad things harder to achieve. Kill's -1 is an example of this -- having a separate killall api is defaulting to a non-fatal situation. Apple's UITableView's is another -- it's so easy for them to rebuild themselves yet instead it crashes on an inconsistency.

If a developer fails to check the return value of a function that can fail, all bets are off. There is no sane default that can safely hide a developer mistake.

Granted, the specific kill() API could have been designed better, but since it's very well established by decades of history, the burden of understanding it lies with the developer.

Re: fork() can fail

#302

Post by __david__ »

djcapelis wrote: post #294
__david__ wrote: post #183

Earlier quoted context omitted.

You are not correct here: There are no fds in the C standard. The only thing defined is fopen/fread/fwrite (which are FILE*). The open/read/write API is only defined by POSIX, where 2 is most definitely stderr.

I cited the exact portions of K&R that specify stdin, stdout and stderr in my original post: K&R B1, 7.5 & 7.6 Section 7.6 explicitly says all three must be open when the program begins. There are equivalent sections in the formal standards, I cited K&R because it was on my shelf. Please stop and bother to check your facts before continuing. You're very close to being accurate (POSIX does define open, but C defines s…

You are wrong because you keep asserting that file descriptor #2 is not defined to be standard error. The only place that defines the interface that uses file descriptors is POSIX and it defines standard error to be file descriptor #2, end of story.

The sources you cite say nothing of file descriptors; they are all references to the standard FILE* interface in C. Those are opaque pointers and have nothing to do with 0, 1, or 2.

You may be confused because I abbreviated "standard error" as "stderr", yet I was never talking about the C standard global "FILE *stderr". That was sloppy of me.

Re: fork() can fail

#303

Post by djcapelis »

__david__ wrote: post #302
djcapelis wrote: post #294

Earlier quoted context omitted.

I cited the exact portions of K&R that specify stdin, stdout and stderr in my original post: K&R B1, 7.5 & 7.6 Section 7.6 explicitly says all three must be open when the program begins. There are equivalent sections in the formal standards, I cited K&R because it was on my shelf. Please stop and bother to check your facts before continuing. You're very close to being accurate (POSIX does define open, but C defines s…

You are wrong because you keep asserting that file descriptor #2 is not defined to be standard error. The only place that defines the interface that uses file descriptors is POSIX and it defines standard error to be file descriptor #2, end of story. The sources you cite say nothing of file descriptors; they are all references to the standard FILE* interface in C. Those are opaque pointers and have nothing to do with…

When you printf to stderr, nothing in that function call is dependent on POSIX semantics. It is dependent on the semantics of C, which requires a stream called stderr to: 1) exist 2) be open when the program starts

POSIX implements this using file descriptors and specifies that stderr is 2.

I said: "strictly speaking, stderr does not have to be 2" which is true. A system is welcome to implement file descriptors and make stderr's something other than 2. It will be a blatant violation of POSIX, but complying with POSIX is optional. Systems that don't just aren't POSIX systems. Complying with the C standard? Not really optional.

Re: fork() can fail

#304

Post by pimlottc »

blueskin_ wrote: post #245
pflanze wrote: post #215

Earlier quoted context omitted.

Note this recent discussion about bash -e, including my post that "the disappointment with set -e is that it does not work everywhere". https://news.ycombinator.com/item?id=8054440

It's nice to have, but I wouldn't rely on it to save me - it's no replacement for checking return codes properly.

Certainly, but it's a good habit to get into, like ``use strict`` in Perl.

Re: fork() can fail

#305

Post by __david__ »

djcapelis wrote: post #303
__david__ wrote: post #302

Earlier quoted context omitted.

You are wrong because you keep asserting that file descriptor #2 is not defined to be standard error. The only place that defines the interface that uses file descriptors is POSIX and it defines standard error to be file descriptor #2, end of story. The sources you cite say nothing of file descriptors; they are all references to the standard FILE* interface in C. Those are opaque pointers and have nothing to do with…

When you printf to stderr, nothing in that function call is dependent on POSIX semantics. It is dependent on the semantics of C, which requires a stream called stderr to: 1) exist 2) be open when the program starts POSIX implements this using file descriptors and specifies that stderr is 2. I said: "strictly speaking, stderr does not have to be 2" which is true. A system is welcome to implement file descriptors and m…

> When you printf to stderr, nothing in that function call is dependent on POSIX semantics.

fprintf(), but yeah. That is exactly what I've been saying, too.

> I said: "strictly speaking, stderr does not have to be 2" which is true.

Ok, but that's just like saying, "strictly speaking it's a valid C to write a bunch of zeros to a file and call it a jpeg."

It might be technically true (complying with the JPEG spec is optional for C programs, too), but it's in no way a reasonable thing to argue for.

Re: fork() can fail

#306

Post by djcapelis »

__david__ wrote: post #305
djcapelis wrote: post #303

Earlier quoted context omitted.

When you printf to stderr, nothing in that function call is dependent on POSIX semantics. It is dependent on the semantics of C, which requires a stream called stderr to: 1) exist 2) be open when the program starts POSIX implements this using file descriptors and specifies that stderr is 2. I said: "strictly speaking, stderr does not have to be 2" which is true. A system is welcome to implement file descriptors and m…

> When you printf to stderr, nothing in that function call is dependent on POSIX semantics. fprintf(), but yeah. That is exactly what I've been saying, too. > I said: "strictly speaking, stderr does not have to be 2" which is true. Ok, but that's just like saying, "strictly speaking it's a valid C to write a bunch of zeros to a file and call it a jpeg." It might be technically true (complying with the JPEG spec is op…

If I was arguing that it was reasonable, I'd have said that. I merely stated C allows it. Which it does.

As for the printf/fprintf flub, totally.

Re: fork() can fail

#307

Post by __david__ »

djcapelis wrote: post #306
__david__ wrote: post #305

Earlier quoted context omitted.

> When you printf to stderr, nothing in that function call is dependent on POSIX semantics. fprintf(), but yeah. That is exactly what I've been saying, too. > I said: "strictly speaking, stderr does not have to be 2" which is true. Ok, but that's just like saying, "strictly speaking it's a valid C to write a bunch of zeros to a file and call it a jpeg." It might be technically true (complying with the JPEG spec is op…

If I was arguing that it was reasonable, I'd have said that. I merely stated C allows it. Which it does. As for the printf/fprintf flub, totally.

> If I was arguing that it was reasonable, I'd have said that. I merely stated C allows it. Which it does.

That's the thing. The C standard does not allow it. The C standard merely never mentions it, which is a different thing entirely. Hence my analogy to JPEGs (which the C standard never mentions either).

And I meant the argument itself is unreasonable. It makes no sense! I could just as well argue that the TCP/IP RFCs allow fd 2 to be something other than standard error. Or the HTTP 2.0 spec. Or the Ecmascript spec. Arguing that something is allowed by a spec that never mentions it and has absolutely nothing to do with it is not an argument.

Re: fork() can fail

#308

Post by blueskin_ »

staunch wrote: post #67
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.

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

    $ mkdir -m 0700

Re: fork() can fail

#309

Post by blueskin_ »

pimlottc wrote: post #304
blueskin_ wrote: post #245

Earlier quoted context omitted.

It's nice to have, but I wouldn't rely on it to save me - it's no replacement for checking return codes properly.

Certainly, but it's a good habit to get into, like ``use strict`` in Perl.

"Perl and line noise are distinguishable. Properly written perl starts with 'use strict'; line noise rarely does."

Re: fork() can fail

#310

Post by SeanLuke »

masklinn wrote: post #230
cpncrunch wrote: post #189

Earlier quoted context omitted.

I think azinman2 was criticizing kill(), not fork(). It would make more sense to have a separate system call, something like killall().

You can criticise both, and more importantly criticise C for its inability to create sensible APIs: in a good design, fork() would have exclusive domains for a PID, an Error and a Child result and you couldn't confuse an error for a pid.

> criticise C for its inability to create sensible APIs

Where in the C manual is kill() described again?

Post reply on HN