object.enable() anti-pattern
Thomas Rachel
nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915 at spamschutz.glglgl.de
Sat May 11 00:21:44 EDT 2013
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
More information about the Python-list
mailing list