Matt Thomas wrote:

> 
> I'd prefer to follow prior art so i think the AIX fcntl FCLOSEM is 
> preferrable to me.  It's not that hard to make fcntl to not check the fd 
> for validity.

well, I originally done this on fcntl but then changed my mind after 
receiving the following argument (from G.A. Drosihn):

"The description for fcntl says the first parameter is:
       a descriptor to be operated on by 'cmd' as
       described below.
For the proposed F_CLOSEM command, it does not operate on the
GIVEN fd, it operates on a whole bunch of OTHER fd's.  This
means that a program which calls fcntl with a cmd-argument
which is different than the programmer thinks is being passed
could cause some pretty painful-to-debug errors in sections of
the program which have nothing to do with the section that has
the bug."

so it's still debatable...

PS. The aix manpage for fcntl is incorrect with this respect (moreover, 
it says fcntl operates on the _open_ file descriptor. not sure, f_closem 
  cares about the fd being open).


> An alternative might be add an F_MAXFD to fcntl which would return the 
> highest opened fd.

yes, but this still requires multiple close() on probably closed 
descriptors, which is a bit suboptimal, given that we can have it done 
in the kernel via similar means.

> 
> The following loop is wrong:
> 
> +       for (i=fdp->fd_lastfile; i>=fd; i--) {
> +               fdrelease(p, i);
> +       }
> 
> It should be:
> 
>         while (fdp->fd_lastfile >= fd)
>                 fdrelease(p, fdp->fd_lastfile);
> 
>

yes, I missed the fd_lastfile update in fdrelease...


>[snip]
Ok, I'll look at the fcntl variant too.

While I am at it, what should the call return? I thought returning EBADF 
if the arg is too large and 0 otherwise. Solaris closefrom() returns 
void (since it just calls close() on fds known to be open (if we ignore 
the race condition).

Also, what if it fails (NFS timeout for instance)?


mouss