[Please CC me on any replies, as I'm not subscribed to the list.]
> Date: Sun, 15 Mar 2015 20:10:30 -0700
> From: David Grayson
>
> Hello. When running under MinGW on Windows, there seems to be a bug
> in Gnulib's fdopendir implementation. Gnulib's fdopendir closes the
> file descriptor that w
On 03/18/2015 09:16 AM, Eli Zaretskii wrote:
An alternative would be to use Gnulib's opendir instead, which seems
to already take care of allocating a file descriptor. However,
Gnulib's opendir is not being linked into the test program; instead,
MinGW's own opendir is.
That doesn't sound right
* lib/fdopendir.c (fdopendir_with_dup): REPLACE_FCHDIR was misspelled.
---
ChangeLog | 5 +
lib/fdopendir.c | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/ChangeLog b/ChangeLog
index 293b863..18d90e2 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2015-03-1
> Date: Wed, 18 Mar 2015 12:33:57 -0700
> From: Paul Eggert
> CC: bug-gnulib@gnu.org
>
> On 03/18/2015 09:16 AM, Eli Zaretskii wrote:
> > An alternative would be to use Gnulib's opendir instead, which seems
> > to already take care of allocating a file descriptor. However,
> > Gnulib's opendir i
On 03/18/2015 12:33 PM, Paul Eggert wrote:
Perhaps someone could investigate why the Gnulib opendir isn't being
used here, as it should be.
I forgot to mention, we made some changes in this area recently due to
problems with opendir and MSVC; please see the thread containing this email:
htt
On 03/18/2015 01:04 PM, Eli Zaretskii wrote:
In this case, "work" means make that file descriptor become valid
again. IOW, it should emulate what happens on Posix systems when
opendir is called: a new file descriptor is allocated.
Many POSIX systems do that, but POSIX doesn't require it and th
> Date: Wed, 18 Mar 2015 13:19:46 -0700
> From: Paul Eggert
> CC: davidegray...@gmail.com, bug-gnulib@gnu.org
>
> On 03/18/2015 01:04 PM, Eli Zaretskii wrote:
> > In this case, "work" means make that file descriptor become valid
> > again. IOW, it should emulate what happens on Posix systems whe
On 03/18/2015 01:26 PM, Eli Zaretskii wrote:
Many POSIX systems do that, but POSIX doesn't require it
OK, but fdopendir's implementation clearly intends for this to happen,
doesn't it?
On Unix-like systems yes. I don' t know about Mingw or other platforms
where REPLACE_FCHDIR is nonzero.
On 03/18/2015 01:33 PM, Paul Eggert wrote:
> It depends on what one means by "work". POSIX allows dirfd to return -1
> and set errno = ENOTSUP. If gnulib dirfd does that on MinGW, dirfd's
> callers should do the right thing when that happens.
I think POSIX 2001 allowed that, but with the openat
> Date: Wed, 18 Mar 2015 17:27:23 -0600
> From: Eric Blake
> CC: bug-gnulib@gnu.org
>
> I think POSIX 2001 allowed that, but with the openat() and friends added
> in POSIX 2008, I think that POSIX now prohibits this implementation, and
> requires that dirfd work rather than giving up with ENOTSUP
10 matches
Mail list logo
