-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Bruno Haible on 12/6/2009 5:18 PM: > - In set_cloexec_flag: You added a call to > dup2 (desc, desc) > But on a POSIX compliant system this is a no-op, since
Not quite. It is the fastest one-syscall sequence for determining whether an fd is open (if it returns -1, then errno is properly set to EBADF; if it returns desc [and desc was not -1], then the fd is valid). Other options, like fcntl(F_GETFL), are not as portable. We've used the same paradigm in other gnulib files (such as utimens.c). But yes, it does require the use of the gnulib dup2 module to work around dup2 bugs. > <http://www.opengroup.org/onlinepubs/9699919799/functions/dup.html> > says: > "If fildes is equal to fildes2, the FD_CLOEXEC flag associated with > fildes2 shall not be changed." > If this is specifically targeted at non-POSIX systems, it would be good to > have > a comment about it. Okay, then, a comment describing that dup2 is used as an EBADF filter, and not for any side effects on cloexec (since there aren't any side effects), would make sense. > > - Regarding dup_safer_flag and fd_safer_flag: I find it important to also > handle > also O_BINARY and O_TEXT, like we do in the pipe2 function (see the doc in > lib/unistd.in.h). pipe2 supports O_TEXT, but pipe2_safer does not: It > respects the O_TEXT flag in the call to pipe2 but then loses it in the call > to > fd_safer_flag (because dup_cloexec has an O_BINARY flag hardwired). Good point. I see two options: Change dup_cloexec to take a flag, so that mingw can handle text vs. binary during the dup. For cygwin, it would have to call setmode() after the fact. Leave dup_cloexec as is, and make fd_safer_flag and/or dup_safer_flag call setmode() after the fact for both cygwin and mingw. I'm leaning quite heavily to the latter, particularly since dup_cloexec is a nice shoe-in for fcntl(F_DUPFD_CLOEXEC), which also lacks the flag for setting text vs. binary. So I'll see about writing such a patch, if you don't beat me to it. > I'm not sure about the way to get it: Should we add O_CLOEXEC support for > all > open-like functions, defining O_CLOEXEC ourselves? Or should we add a > O_GL_CLOEXEC that is supported only by selected gnulib functions? The latter > approach can serve as a step-by-step approach to the complete support of > O_CLOEXEC. Well, we've been talking for a couple of months about implementing O_CLOEXEC in gnulib. I'm not sure whether (temporarily) using O_GL_CLOEXEC is going to get us there any faster than just doing the work. > 2009-12-06 Bruno Haible <br...@clisp.org> > > * lib/cloexec.c (dup_cloexec): Fix handling of _gl_register_dup return > value. Thanks for catching that. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkscUe8ACgkQ84KuGfSFAYCoSwCgmldI7mzd96m2vy6yHs4L7bbJ KqcAoLT8HsaPg81HmPs5jPes5N4NAEXw =amhn -----END PGP SIGNATURE-----
