Re: fwcontrol -r missing a close() call

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