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