David Grayson wrote:
+ ASSERT (dup2 (fd, fd) == fd);
Thanks, I installed a patch along those lines.
> Date: Sun, 22 Mar 2015 01:51:45 -0700
> From: David Grayson
>
> On Wed, Mar 18, 2015 at 9:16 AM, Eli Zaretskii wrote:
> > Another aside: I think you are making your life much harder by using
> > these kludges. The recommended way of building GNU software with
> > MinGW is to use the MSYS Bash
On Wed, Mar 18, 2015 at 9:16 AM, Eli Zaretskii wrote:
> Another aside: I think you are making your life much harder by using
> these kludges. The recommended way of building GNU software with
> MinGW is to use the MSYS Bash and tools, including MSYS Make.
You were right Eli. Your comment made m
> Date: Fri, 20 Mar 2015 09:55:07 -0700
> From: David Grayson
> Cc: Eli Zaretskii
>
> 1) In the specification of fdeopdir, POSIX requires that
> closedir(fdopendir(fd)) will close fd, assuming fdopendir was
> successful. That patch does nothing to associate the duplicated file
> descriptor to t
Paul, Eli, and Eric: thanks for looking into this and providing
information about the problem.
On Thu, Mar 19, 2015 at 12:18 PM, Paul Eggert wrote:
> On 03/19/2015 09:19 AM, Eli Zaretskii wrote:
>> I suggest the following simpler
>> change instead:
> Thanks, I installed that, with a briefer code
On 03/19/2015 09:19 AM, Eli Zaretskii wrote:
I suggest the following simpler
change instead:
Thanks, I installed that, with a briefer code comment.
Eric's approach sounds like it'd be better in general, but it'll take
more work and in the mean time if this patch fixes 'grep' on mingw then
tha
> Date: Wed, 18 Mar 2015 13:40:29 -0700
> From: Paul Eggert
> CC: davidegray...@gmail.com, bug-gnulib@gnu.org
>
> 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,
>
> Date: Wed, 18 Mar 2015 13:13:25 -0700
> From: Paul Eggert
> CC: bug-gnulib@gnu.org
>
> 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 are
> 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
> 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
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
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.
> 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: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
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
> 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 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
[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/15/2015 08:10 PM, David Grayson wrote:
To make fdopendir be POSIX compliant on MinGW, it seems like you would
want to somehow associate the fd with the DIR pointer even if the fd
isn't used by typical dirent functions. Then when closedir is called,
you would want to retrieve that fd and cl
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 was passed to it as an argument. It then tries
to reopen the directory using the same file descriptor, but that
doesn't seem to work in Min
20 matches
Mail list logo
