Am 10.05.2013 15:22 schrieb Roy Smith:
That's correct. But, as described above, the system makes certain
guarantees which allow me to reason about the existence or non-existence
os such entries.
Nevertheless, your 37 is not a FD yet.
Let's take your program:
#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <assert.h>
int main(int argc, char** argv) {
int max_files = getdtablesize();
assert(max_files >= 4);
Until here, the numbers 3 toll max_files may or may not be FDs.
for (int i = 3; i < max_files; ++i) {
close(i);
}
Now they are closed; they are definitely no longer FDs even if they
were. If you would use them in a file operation, you'd get a EBADF which
means "fd is not a valid file descriptor".
dup(2);
From now on, 3 is a FD and you can use it as such.
char* message = "hello, fd world\n";
write(3, message, strlen(message));
}
No, what I've done is taken advantage of behaviors which are guaranteed
by POSIX.
Maybe, but the integer numbers get or los their property as a file
descriptor with open() and close() and not by assigning them to an int.
Thomas
--
http://mail.python.org/mailman/listinfo/python-list
