Fun with file descriptors [LWN.net]

Fun with file descriptors

Posted Jun 11, 2007 10:32 UTC (Mon) by RobSeace (subscriber, #4435)
In reply to: Fun with file descriptors by nlucas
Parent article: Fun with file descriptors

No, the only thing guaranteed is that any particular call that creates a new FD will return the lowest numbered FD currently available... That's it... It doesn't guarantee that nothing else outside the app code will use up any FDs... And, no sane code would EVER make such a brain-dead assumption... Because, any programmer worth a damn KNOWS for a fact that LOTS of library code DOES indeed open up lots of FDs of its own for various uses... So, unless you have complete control over the code, and aren't making any library function calls, you better make NO assumptions over what particular FD number you are going to get assigned at any particular time... You can be guaranteed it's the lowest currently available number, but that doesn't mean a whole lot if you don't know all of the currently open FDs...

For instance, this common behavior is fairly reasonable:

close (0);
open ("/dev/null", O_RDONLY);

Assuming that the open() will get FD# 0... That's reasonable enough, because it's hard to imagine the need for either close() or open() to create a persistent extra FD of its own for some use behind your back, and this sort of behavior has historically always worked... But, if you add any other lib function calls between the close() and the open(), you're just asking for trouble, and you can't be too surprised when it doesn't work anymore... (Plus, if you really wanted to write good code, you'd instead use dup2() or freopen() or something, to guarantee assignment of the desired FD#...)

(Log in to post comments)

Fun with file descriptors

Posted Jun 11, 2007 12:29 UTC (Mon) by nlucas (subscriber, #33793) [Link]

Fair enough. To me, even the lowest number fd guarantee is strange, so I though it was some POSIX weirdness (along with other weird behaviours for compatibility sake).

Anyway, even the { close(0);open(...); } is strange, as it doesn't take into account multithreading, so I wouldn't ever do anything like that, even in single threaded applications (I never know when a piece of code that seems trivial will be latter "copy/pasted" to a multithreaded application).

Fun with file descriptors

Posted Jun 14, 2007 7:58 UTC (Thu) by slamb (guest, #1070) [Link]

Avoiding code which is broken if copy'n'pasted into the wrong context is a hopeless job - the best you can do is state your code's assumptions, and whoever adds code (whether pasted or not) must take responsibility for it.

Anyway, I can't really imagine when you'd ever want to replace stdin/stdout/stderr while multiple threads are going, so I don't know why someone would paste this there.

Fun with file descriptors

Posted Sep 15, 2007 6:40 UTC (Sat) by schabi (subscriber, #14079) [Link]

You wrote:

For instance, this common behavior is fairly reasonable:

close (0);
open ("/dev/null", O_RDONLY);

This one is broken as sonn as threads are involved - typical race condition, another thread could do anything between close(0) and open().