Re: bash: Correct usage of F_SETFD
On 11/23/2010 07:42 AM, Matthew Wilcox wrote: > The POSIX definition can be found here: > http://www.opengroup.org/onlinepubs/009695399/functions/fcntl.html > >> | In practice, there aren't any such systems; but POSIX warns that current >> | practice is no indicator of future systems, and that read-modify-write >> | is the only way to use F_SETFD. >> >> Yes, that seems to make more sense. > > I think future flags will be created such that they default to off, > and bash would have to affirmitively set them in order to use them. Not true. An implementation can reasonably define a new flag to off for backwards-compatible behavior, and on for POSIX-compatible behavior, if there is a case where traditional and POSIX behavior differ. POSIX permits additional bits to be on, and in fact requires that applications leave those additional bits unchanged, in the very case where those additional bits are essential for maintaining a POSIX-compatible environment. > > So if bash is the one creating its file descriptors, there's no need to > use R/M/W since it knows what the state of them are. No, bash cannot reasonably know what the implementation's default bit state is, and blindly setting all other bits to zero is very possibly a bug, and easy enough to avoid by using the full R/M/W. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: bash: Correct usage of F_SETFD
Eric Blake [ebl...@redhat.com] wrote: | > | > So if bash is the one creating its file descriptors, there's no need to | > use R/M/W since it knows what the state of them are. | | No, bash cannot reasonably know what the implementation's default bit | state is, and blindly setting all other bits to zero is very possibly a | bug, and easy enough to avoid by using the full R/M/W. Besides, if user sets a flag on the fd and execs bash, bash would clobber the flag. IOW, assuming that bash is the one creating the fd is not always safe right ? Thanks, Sukadev
Re: bash: Correct usage of F_SETFD
On Mon, Nov 22, 2010 at 04:04:46PM -0800, Sukadev Bhattiprolu wrote: > Eric Blake [ebl...@redhat.com] wrote: > | On 11/22/2010 03:16 PM, Chet Ramey wrote: > | >> include/filecntl.h in bash-4.1 has following: > | >> > | >> #define SET_CLOSE_ON_EXEC(fd) (fcntl ((fd), F_SETFD, FD_CLOEXEC)) > | >> > | >> Is that really the correct/intended usage of F_SETFD ? > | > > | > F_SETFDSet the close-on-exec flag associated with fildes > to > | > the low order bit of arg (0 or 1 as above). > > Is that the POSIX definition ? Following man page does not limit F_SETFD to > FD_CLOEXEC: > > http://www.kernel.org/doc/man-pages/online/pages/man2/fcntl.2.html > > F_SETFD (long) > Set the file descriptor flags to the value specified by arg. The POSIX definition can be found here: http://www.opengroup.org/onlinepubs/009695399/functions/fcntl.html > | In practice, there aren't any such systems; but POSIX warns that current > | practice is no indicator of future systems, and that read-modify-write > | is the only way to use F_SETFD. > > Yes, that seems to make more sense. I think future flags will be created such that they default to off, and bash would have to affirmitively set them in order to use them. So if bash is the one creating its file descriptors, there's no need to use R/M/W since it knows what the state of them are. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step."
