Dan Nelson wrote: > In the last episode (Aug 19), Andre Guibert de Bruet said: > > open("/dev/fw0.0",0x2,01001132500) = 3 (0x3) > > ioctl(3,FW_IBUSRST,0xbfbff400) = 0 (0x0) > > exit(0x0) > > process exit, rval = 0 > > > > We're not closing fd #3 before exiting the process. This is also the case > > with 4.8-STABLE. > > > > Semantics? Nit-picking? Both? :) > > Why bother closing a fd when exit() will do it for you? You don't > close stdout when you're done with it :)
I used to think this way too. Then I had to deal with some multithreaded applications that failed to pthread_join() or pthread_kill() their threads, AND with applications that had called blocking calls on fd's in one thread, and then closed the fd's out from under the blocking calls in another, thus triggering a kernel panic, AND applications which failed to realize a signal may interrupt a close() call, making it return -1 with errno == EINTR, thus leaking descriptors on any close that was interrupted by a signal. After dealing with all that, I have to say that the lack of an explicit close of an fd is an incredibly bad example for any programmer who might read your code. As such, it should be fixed, since it may be your own foot you are shooting in the future by providing a bad example to some programmer that then writes code that you decide you want to run on your machine. Don't even get me started on the people who think that all the world is Linux, and fail to bzero() their sockaddr_in's before filling out only some of the structure members, and having all the various connect/bind/other socket related calls fail on non-Linux machines because the programmers didn't know how to properly use the interfaces they were calling. -- Terry _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"