2 ms·

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

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.

__david__ 12y ago
> 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.
- djcapelis 12y ago
  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.
  - __david__ 12y ago
    > 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.

__david__ 12y ago

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

djcapelis 12y ago
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.
- __david__ 12y ago
  > 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.