2

I am currently writing a piece of code whose intended usage is this:

program input.txt output.txt

or

program input.txt

in which case it defaults to stdout.

This is the code I have now (within main()):

FILE *outFile;
if (argc < 3) {
        outFile = stdout;
    } else {
        fprintf(stdout, "Will output to file %s\n", argv[2]);
        outFile = fopen(argv[2], "w");
        if (outFile == NULL) {
            fprintf(stderr, "ERR: Could not open file %s. Defaulting to stdout\n", argv[2]);
            outFile = stdout;
        }
    }
/* ... write stuff to outFile... */
if (argc < 3 && outFile != stdout) {
        fclose(outFile);
    }

These are my concerns: first of all, will this successfully open and close outFile when provided? Also, will this successfully not close stdout? Can anything bad happen if I close stdout?

Also, is this portable? I compile with gcc but this project will be evaluated by a professor using Windows.

Apologies if this is a bit of a mess of a question. I come from Python and am not a CS major (I'm studying mathematics).

Riccardo Orlando
  • 207
  • 2
  • 10

3 Answers3

2

Yes, it's portable and it's okay.

Soner from The Ottoman Empire
  • 18,731
  • 3
  • 79
  • 101
2

Yes, it's portable. You assigned outfile = stdout, so they will be equal as long as you don't reassign either of them elsewhere in the program.

You don't really need the argc < 3 test as well -- the two conditions should always be the same, since you only do the assignment when that's true.

Barmar
  • 741,623
  • 53
  • 500
  • 612
  • imho it's penny ante nuance indeed in this case. https://softwareengineering.stackexchange.com/questions/201896/what-is-short-circuiting-in-c-like-languages, however, in programming concept `NULL` checking is done at first most generally – Soner from The Ottoman Empire Jun 14 '18 at 19:33
  • @RiccardoOrlando you do not need null check in this code. If `fopen` fails, `outfile` will point to `stdout`, so null check is not necessary. – SergeyA Jun 14 '18 at 19:37
  • @snr ` in programming concept NULL checking is done at first` - do you have any proof to substantiate this claim? – SergeyA Jun 14 '18 at 19:39
  • @SergeyA Didn't notice that he did that. Defaulting to stdout when the named file can't be opened is a very unusual thing. – Barmar Jun 14 '18 at 19:40
  • 1
    Actually, I'd probably write something like `if (outfile && outfile != stdout)` – Barmar Jun 14 '18 at 19:43
  • `outfile` cannot be null at that point so it is redundant to check for it – M.M Jun 14 '18 at 21:33
  • @M.M I know, that's why I removed that from my answer. I didn't realize at the time that he defaulted it to `stdout` when `fopen()` fails. – Barmar Jun 14 '18 at 21:49
1

In any program that writes significant data to stdout, you should close stdout immediately before exiting, so that you can check for and report delayed write errors. (Delayed write errors are a design mistake; it ought to be impossible for fclose or close to fail. But we are stuck with them.)

The usual construct is, at the very end of main,

if (ferror(stdout) || fclose(stdout)) {
    perror("stdout: write error");
    return 1;
}
return 0;

Some programs stick an fflush in there too, but ISO C requires fclose to perform a fflush, so it shouldn't be necessary. This construct is entirely portable.

It's important for this to be the very last thing you do before exiting. It is relatively common for libraries to assume that stdout is never closed, so they may malfunction if you call into them after closing stdout. stdin and stderr are also troublesome that way, but I've yet to encounter a situation where one wanted to close those.

It does sometimes happen that you want to close stdout before your program is completely done. In that case you should actually leave the FILE open but close the underlying "file descriptor" and replace it with a dummy.

int rfd = open("/dev/null", O_WRONLY);
if (rfd == -1) perror_exit("/dev/null");
if (fflush(stdout) || close(1)) perror_exit("stdout: write error");
dup2(rfd, 1);
close(rfd);

This construct is NOT portable to Windows. There is an equivalent, but I don't know what it is. It's also not thread-safe: another thread could call open in between the close and dup2 operations and be assigned fd 1, or it could attempt to write something to stdout in that window and get a spurious write error. For thread safety you have to duplicate the old fd 1 and close it via that handle:

// These allocate new fds, which can always fail, e.g. because
// the program already has too many files open.
int new_stdout = open("/dev/null", O_WRONLY);
if (new_stdout == -1) perror_exit("/dev/null");
int old_stdout = dup(1);
if (old_stdout == -1) perror_exit("dup(1)");

flockfile(stdout);
if (fflush(stdout)) perror_exit("stdout: write error");
dup2 (new_stdout, 1); // cannot fail, atomically replaces fd 1
funlockfile(stdout);

// this close may receive delayed write errors from previous writes
// to stdout
if (close (old_stdout)) perror_exit("stdout: write error");

// this close cannot fail, because it only drops an alternative
// reference to the open file description now installed as fd 1
close (new_stdout);

Order of operations is critical: the open, dup and fflush calls must happen before the dup2 call, both close calls must happen after the dup2 call, and stdout must be locked from before the fflush call until after the dup2 call.

Additional possible complications, dealing with which is left as an exercise:

  • Cleaning up temporary fds and locks on error, when you don't want to stop the whole program on error
  • If the thread might be canceled mid-operation
  • If a concurrent thread might call fork and execve mid-operation
zwol
  • 135,547
  • 38
  • 252
  • 361
  • Your first code doesn't close the file if there was an error, what is the rationale there? – M.M Jun 14 '18 at 21:34
  • @M.M If there was already a write error, one needs to report _that_, but reporting subsequent errors (if any) is not useful -- what's the user going to do differently for two write errors than they would for one? – zwol Jun 14 '18 at 21:41