On Fri, Aug 21, 2009 at 12:42 AM, Eric Blake 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 this parti
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
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
assumin
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 loo
ifdef F_GETLK
+case F_GETLK:
+# if F_GETLK
+# endif
+#endif
+
+#ifdef F_SETLK
+ case F_SETLK:
+# if F_SETLK
+# endif
+#endif
+
+#ifdef F_SETLKW
+case F_SETLKW:
+# if F_SETLKW
+# endif
+#endif
+
+ ;
+}
+}
+
+int
+main (int argc, char **argv)
+{
+ int flags;
+ if (argc
-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 argum
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 lo
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 get
tion dup_noinherit should be taught to handle ENOSYS failure, along
these lines (and then move 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
inde
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
rev
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, po
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
-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
13 matches
Mail list logo
