Is close/fclose on stdin guaranteed to be correct?

Question

It seems as though the following calls do what you'd expect (close the stream and not allow any further input - anything waiting for input on the stream returns error), but is it guaranteed to be correct across all compilers/platforms?

close(fileno(stdin));
fclose(stdin);

you can just fclose(stdin), it will call close() on the file handle. — Jason Coco, Nov 13 '08 at 20:05

score 28 · Answer 1 · answered May 08 '11 at 04:23

fclose(stdin) causes any further use of stdin (implicit or explicit) to invoke undefined behavior, which is a very bad thing. It does not "inhibit input".

close(fileno(stdin)) causes any further attempts at input from stdin, after the current buffer has been depleted, to fail with EBADF, but only until you open another file, in which case that file will become fd #0 and bad things will happen.

A more robust approach might be:

int fd = open("/dev/null", O_WRONLY);
dup2(fd, 0);
close(fd);

with a few added error checks. This will ensure that all reads (after the current buffer is depleted) result in errors. If you just want them to result in EOF, not an error, use O_RDONLY instead of O_WRONLY.

Unfortunately your solution is not portable, not compliant with C99. — nowox, Mar 10 '20 at 13:59
@nowox: It's outside the scope of the base C language, which simply doesn't have the concepts needed for you to do such a thing, but doesn't in any way forbid defining it for a more restrictive specification that does. — R.. GitHub STOP HELPING ICE, Mar 10 '20 at 16:39

score 14 · Answer 2 · answered Nov 13 '08 at 20:05

14

DO NOT DO a close on fileno(FILE*). FILE is a buffering object. Looking into its implementation and meddling with its state carries all the caveats and dangers that would come with similar misbehavior on any other software module.

Don't do it.

AGH. Seriously. Nasty.

answered Nov 13 '08 at 20:05

Sniggerfardimungus

11,583
10
52
97

7

In fact, doing the close() before the fclose() is guaranteed to make fclose() fail if there is any outstanding data to flush. (In a more general case, where the might be other code between the close() and fclose(), fclose() might simply write to the wrong file!) – Jonathan Leffler Nov 15 '08 at 22:54
2

This... doesn't... technically answer the question. – MD XF Feb 01 '17 at 01:42
1

This does: The behavior of the OP's code would be undefined. It's unlikely that his implementation of fclose would detect that the fd had been closed. If he had other things going on between the calls to close and fclose, then there's another nasty possibility: having just closed a file descriptor, the next call to open() is most likely - in practice - to reuse that file descriptor. What would happen if you called close on the underlying descriptor, opened another descriptor with the same index, then called fclose? That last open()'s fd would certainly be bad, at the very least. – Sniggerfardimungus Feb 01 '17 at 23:51

score 3 · Accepted Answer · answered Nov 13 '08 at 20:08

Nothing is guaranteed correct across every possible operating system. However, calling fclose(stdin) will work on any POSIX compliant operating system as well as Windows operating systems, so you should hit pretty much anything in general use at the moment.

As stated by the previous answer as well as my comment, there is no need to call close on the file handle. fclose() will properly close everything down for you.

Is close/fclose on stdin guaranteed to be correct?

3 Answers3

Linked