Not quite. That is according to POSIX, but not the C standard.

stderr is defined by the C standard. POSIX is a standard followed by many of the systems that run C.

Strictly speaking, stderr does not have to be 2. It wouldn't comply with POSIX in that case, but it would still be C.

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

Note, however, that these were Unix systems where we encountered the problem, so they should have been POSIX-compliant.

It's quite true! It is worth noting that many systems people call unix are not POSIX compliant, but most try!