bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Does HIGH_FD_MAX have to be so low?


From: Mike Stroyan
Subject: Re: Does HIGH_FD_MAX have to be so low?
Date: Thu, 19 Oct 2006 13:41:24 -0600
User-agent: Mutt/1.5.9i

On Thu, Oct 19, 2006 at 03:33:37PM -0400, Chet Ramey wrote:
> Mike Stroyan wrote:
> 
> >   Looking at open_shell_script() in shell.c and move_to_high_fd() in
> > general.c, I find that the code will force the use of fildes 255,
> > (HIGH_FD_MAX), for reading the shell script when getdtablesize() reports
> > that the maximum allowed file descriptor value is greater than 255.
> > In this particular case the maximum file descriptor value was 1023,
> > which would have stayed out of the way of the application's use.
> 
> If you look closely at move_to_high_fd(), you see that it attempts to
> avoid file descriptors already in use.  Only if fcntl(fd, F_GETFD, ...)
> returns -1 does it conclude that file descriptor fd is available.
> 
> One can debate whether or not we should be checking explicitly for
> EBADF, but that's the only value of errno that's valid for F_GETFD
> anyway.
> 
> I'd be interested in knowing why fcntl didn't return -1, if the parent
> process really did leave the file descriptor open and didn't set the
> close-on-exec flag.

  move_to_high_fd() only avoid open file descriptors if the
check_new parameter is non-zero.  open_shell_script() calls
move_to_high_fd() with a check_new value of 0.  The other two callers
of the function do pass in a check_new value of 1.

-- 
Mike Stroyan, mike.stroyan@hp.com




reply via email to

[Prev in Thread] Current Thread [Next in Thread]