On Fri, Aug 21, 2009 at 12:42 AM, Eric Blakee...@byu.net wrote:
Interesting. What happens if you pass the bit value of O_CLOEXEC to an
older kernel that doesn't understand it - does the open fail with ENOSYS,
or does it cause a kernel panic (requiring a reboot for recovery)?
I haven't tested
Hi Eric,
First order of business - we need two modules based on the fcntl name, one
for the header ... and one for the function.
Yes, absolutely.
Your 3 patches look all fine, except for the mingw replacement of fcntl().
+static int
+dupfd (int fd, int desired_fd)
+{
+ /* Although this
Eric Blake wrote:
we also need to
tweak the O_NOINHERIT flag of an existing fd without having to use dup in
cloexec.c (I'm hoping the windows functions GetHandleInformation and
SetHandleInformation work here).
I don't see how to make it work without a lot of dup() calls and without
assuming
On 08/22/2009 03:25 PM, Bruno Haible wrote:
Eric Blake wrote:
we also need to
tweak the O_NOINHERIT flag of an existing fd without having to use dup in
cloexec.c (I'm hoping the windows functions GetHandleInformation and
SetHandleInformation work here).
I don't see how to make it work without
I'd rather keep the open module alone. However, there's an interesting
thing that goes to our advantage. You cannot detect O_CLOEXEC at
build-time, otherwise binary compatibility with older kernels goes
south: I did this for GNU Smalltalk and two people reported that they
needed to reboot to
Yes, but unlike dup2.c where we are emulating fcntl(n, F_DUPFD, 3), you
are now introducing an arbitrarily large target
Actually, the same happens in dup2.c; the code I referred to is the one
emulating dup2 using dup. You are confusing with your own
popen-safer.c, which indeed has a very
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paolo Bonzini on 8/21/2009 1:34 AM:
(or, is mingw subject to a compile-time maximum of open fds
where we can just return EMFILE up front?).
EMFILE is more appropriate that EBADF; POSIX states this for fcntl:
[EMFILE]
The argument
On 08/20/2009 10:18 AM, Bruno Haible wrote:
Paolo Bonzini wrote:
Why not just implement a fcntl replacement, supporting only
F_GETFD/F_SETFD for now (and maybe in the future F_DUPFD and
F_DUPFD_CLOEXEC, as you mention below)?
One thing at a time. I agree with Eric. I would have a hard time
Paolo Bonzini wrote:
Why not just implement a fcntl replacement, supporting only
F_GETFD/F_SETFD for now (and maybe in the future F_DUPFD and
F_DUPFD_CLOEXEC, as you mention below)?
One thing at a time. I agree with Eric. I would have a hard time
reviewing a patch that implements fcntl,
And this patch also includes a first use of O_CLOEXEC; I'm debating about
adding more O_CLOEXEC support throughout gnulib, a piece at a time.
You are beating me to it. :-)
And since fcntl is not portable, it
would be nice to add this convenience prototype to cloexec.h:
/* Return true if FD
this into whatever wrapper we use in lib/open.c
when making O_CLOEXEC support more generic). In other words, do I need to
install something like this?
diff --git a/lib/popen-safer.c b/lib/popen-safer.c
index 2182a2c..27c62a4 100644
- --- a/lib/popen-safer.c
+++ b/lib/popen-safer.c
@@ -23,6 +23,7
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 8/19/2009 11:06 AM:
I went ahead and implemented popen_safer.
And this patch also includes a first use of O_CLOEXEC; I'm debating about
adding more O_CLOEXEC support throughout gnulib, a piece at a time.
cloexec support
12 matches
Mail list logo
