4 ms·

Wow that's a really wild story, but I think it's also pretty different. fork() returning -1 is defined behavior, as is true for many functions. Whereas not ha

Wow that's a really wild story, but I think it's also pretty different. fork() returning -1 is defined behavior, as is true for many functions. Whereas not having stderr open defies everything about the C standard I/O. (K&R B1, 7.5 & 7.6) Note however, that strictly speaking stderr does not have to be 2. It can be any number, but it has to be whatever the include file says it is, so if you don't specify the stream as stderr but instead write to stream 2, that would potentially be a problem. That said, if for some reason you have a program completely defying the C standard, you can test whether the streams are open (and they are explicitly defined as having to be open) using fcntl and testing for EBADF at the very beginning of the program.

__david__ 12y ago
> Note however, that strictly speaking stderr does not have to be 2. It Nope. On POSIX systems stderr is defined as 2: http://pubs.opengroup.org/onlinepubs/9699919799/functions/stdin.html http://pubs.opengroup.org/onlinepubs/9699919799/functions/st... > The following symbolic values in <unistd.h> define the file descriptors > that shall be associated with the C-language stdin, stdout, and stderr > when the application is started: > > STDIN_FILENO > Standard input value, stdin. Its value is 0. > STDOUT_FILENO > Standard output value, stdout. Its value is 1. > STDERR_FILENO > Standard error value, stderr. Its value is 2.
- djcapelis 12y ago
  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.
  - __david__ 12y ago
    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.
    - djcapelis 12y ago
      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?
      - __david__ 12y ago
        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.
        djcapelis 12y ago
        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
  - AnimalMuppet 12y ago
    Note, however, that these were Unix systems where we encountered the problem, so they should have been POSIX-compliant.
    - djcapelis 12y ago
      It's quite true! It is worth noting that many systems people call unix are not POSIX compliant, but most try!

__david__ 12y ago

> Note however, that strictly speaking stderr does not have to be 2. It Nope. On POSIX systems stderr is defined as 2: http://pubs.opengroup.org/onlinepubs/9699919799/functions/stdin.html http://pubs.opengroup.org/onlinepubs/9699919799/functions/st... > The following symbolic values in <unistd.h> define the file descriptors > that shall be associated with the C-language stdin, stdout, and stderr > when the application is started: > > STDIN_FILENO > Standard input value, stdin. Its value is 0. > STDOUT_FILENO > Standard output value, stdout. Its value is 1. > STDERR_FILENO > Standard error value, stderr. Its value is 2.

djcapelis 12y ago
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.
- __david__ 12y ago
  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.
  - djcapelis 12y ago
    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?
    - __david__ 12y ago
      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.
      - djcapelis 12y ago
        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
- AnimalMuppet 12y ago
  Note, however, that these were Unix systems where we encountered the problem, so they should have been POSIX-compliant.
  - djcapelis 12y ago
    It's quite true! It is worth noting that many systems people call unix are not POSIX compliant, but most try!