Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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 stderr and some functions to print to it, the underlying mechanics are the choice of the implementing system.) But don't you think it would be nice to check that I actually am before writing yet another post simply asserting I'm wrong?



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.


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.


> 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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: