KO Myung-Hun wrote:
> This patch breaks compilation like this:
>
> -
> gcc -DHAVE_CONFIG_H -I. -I.. -DGNULIB_STRICT_CHECKING=1 -g -O2 -MT
> fdopendir.o -MD -MP -MF .deps/fdopendir.Tpo -c -o fdopendir.o fdopendir.c
> fdopendir.c:34:5: error: #error "unexpected configuration:
> GNULIB_defined
t; (dirfd): Use Windows code path.
>> * lib/fdopendir.c (fdopendir): Use Windows code path.
>> * lib/opendir.c (opendir): Use Windows code path.
>> * m4/closedir.m4 (REPLACE_CLOSEDIR): Use Windows code path.
>> * m4/dirent_h.m4 (DIR_HAS_FD_MEMBER): Use Windows code path.
>>
KO Myung-Hun wrote:
> * lib/closedir.c (closedir): Use Windows code path.
> * lib/dirent.in.h (_gl_register_dirp_fd, _gl_unregister_dirp_fd):
> Remove.
> * lib/dirfd.c (_gl_register_dirp_fd, _gl_unregister_dirp_fd): Remove.
> (dirfd): Use Windows code path.
> * lib/fdopendir.
* lib/closedir.c (closedir): Use Windows code path.
* lib/dirent.in.h (_gl_register_dirp_fd, _gl_unregister_dirp_fd):
Remove.
* lib/dirfd.c (_gl_register_dirp_fd, _gl_unregister_dirp_fd): Remove.
(dirfd): Use Windows code path.
* lib/fdopendir.c (fdopendir): Use Windows code path.
* lib/opendir.c
Hi/2.
Bruno Haible wrote:
> KO Myung-Hun wrote:
>>> dirfd is specified at
>>> https://pubs.opengroup.org/onlinepubs/9699919799/functions/dirfd.html
>>> Which says that if "The dirp argument does not refer to a valid directory
>>> stream"
>>> the function may fail with error EINVAL. It may alterna
KO Myung-Hun wrote:
> > dirfd is specified at
> > https://pubs.opengroup.org/onlinepubs/9699919799/functions/dirfd.html
> > Which says that if "The dirp argument does not refer to a valid directory
> > stream"
> > the function may fail with error EINVAL. It may alternatively simply crash
> > ("the
Bruno Haible wrote:
> KO Myung-Hun wrote:
>>> @@ -78,11 +82,17 @@ _gl_unregister_dirp_fd (int fd)
>>> int
>>> dirfd (DIR *dir_p)
>>> {
>>> +#if GNULIB_defined_DIR
>>> + int fd = dir_p->fd_to_close;
>>
>> dirfd() allows to take an invalid `dir_p' ?
>
> No; this must be a misunderstanding.
>
KO Myung-Hun wrote:
> > @@ -78,11 +82,17 @@ _gl_unregister_dirp_fd (int fd)
> > int
> > dirfd (DIR *dir_p)
> > {
> > +#if GNULIB_defined_DIR
> > + int fd = dir_p->fd_to_close;
>
> dirfd() allows to take an invalid `dir_p' ?
No; this must be a misunderstanding.
dirfd is specified at
https://p
Hi/2.
Bruno Haible wrote:
> On native Windows, I see a test failure:
>
> FAIL: test-fdopendir
>
>
> ../../gltests/test-fdopendir.c:76: assertion 'dup2 (fd, fd) == -1' failed
> FAIL test-fdopendir.exe (exit status: 3)
>
> The cause
On native Windows, I see a test failure:
FAIL: test-fdopendir
../../gltests/test-fdopendir.c:76: assertion 'dup2 (fd, fd) == -1' failed
FAIL test-fdopendir.exe (exit status: 3)
The cause of the problem is that POSIX [1] says:
"Upon calling closedir() the
with dirp to
dirp_fd_list.
(_gl_unregister_dirp_fd): New. Unregister fd with closing it.
(dirfd): Implemented for kLIBC.
* lib/fdopendir.c (fdopendir): Implemented for kLIBC.
* lib/opendir.c (opendir): New. Register fd and dirp pair if open()
succeeds.
* m4/closedir.m4 (gl_FUNC_CLOSEDIR): Replace if
with dirp to
dirp_fd_list.
(_gl_unregister_dirp_fd): New. Unregister fd with closing it.
(dirfd): Implemented for kLIBC.
* lib/fdopendir.c (fdopendir): Implemented for kLIBC.
* lib/opendir.c (opendir): New. Register fd and dirp pair if open()
succeeds.
* m4/closedir.m4 (gl_FUNC_CLOSEDIR): Replace if
with dirp to
dirp_fd_list.
(_gl_unregister_dirp_fd): New. Unregister fd with closing it.
(dirfd): Implemented for kLIBC.
* lib/fdopendir.c (fdopendir): Implemented for kLIBC.
* lib/opendir.c (opendir): New. Register fd and dirp pair if open()
succeeds.
* m4/closedir.m4 (gl_FUNC_CLOSEDIR): Replace if
: KO Myung-Hun
Date: Fri, 28 Nov 2014 16:47:12 +0900
Subject: [PATCH] opendir, closedir, dirfd, fdopendir: port to OS/2 kLIBC
* lib/closedir.c (closedir): Unregister fd if closedir() succeeds.
* lib/dirent.in.h (_gl_register_dirp_fd, _gl_unregister_dirp_fd):
Declare on kLIBC.
* lib/dirfd.c (stru
KO Myung-Hun wrote:
-# if REPLACE_FCHDIR
+# if REPLACE_FCHDIR || defined __KLIBC__
int fd = dirfd (dirp);
# endif
Would it be cleaner to change that "defined __KLIBC__" to "REPLACE_DIRFD"?
with dirp to
dirp_fd_list.
(_gl_unregister_dirp_fd): New. Unregister fd with closing it.
(dirfd): Implemented for kLIBC.
* lib/fdopendir.c (fdopendir): Implemented for kLIBC.
* lib/opendir.c (opendir): New. Register fd and dirp pair if open()
succeeds.
* m4/closedir.m4 (gl_FUNC_CLOSEDIR): Replace if
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
them.
However, here is a small patch for Gnulib that adds a test to make
sure that fdopendir does not close the file descriptor. I hereby
release it into public domain.
(I hope it's formatted correctly and isn't messed up by Gmail's line wrapping.)
--- a/tests/test-fdopendir.c
> 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
ith a briefer code comment.
I have not tested Eli's simpler change, but I expect it would fix the
bug in grep, and the bug in by test program at the beginning of this
thread. However, two things about that patch seem wrong to me:
1) In the specification of fdeopdir, POSIX requires that
close
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
ation 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.
Well, this bug report clearly indicates that fdopendir's callers
expect the file descriptor to rem
> 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
e
descriptor with which the directory was open must remain open after
fdopendir returns. It clearly is what Grep assumes.
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
t;work".
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. Otherwise,
fdopendir will still return with the original FD invalid, which was
what triggered this report in the first place.
-18 Paul Eggert
+
+ fdopendir: fix typo in comment
+ * lib/fdopendir.c (fdopendir_with_dup): REPLACE_FCHDIR was misspelled.
+
2015-03-09 Eric Blake
error: document all entry points provided
diff --git a/lib/fdopendir.c b/lib/fdopendir.c
index 9dc1e7b..117baa9 100644
--- a
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 clo
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 f
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
with dirp to
dirp_fd_list.
(_gl_unregister_dirp_fd): New. Unregister fd with closing it.
(dirfd): Implemented for kLIBC.
* lib/fdopendir.c (fdopendir): Implemented for kLIBC.
* lib/opendir.c (opendir): New. Register fd and dirp pair if open()
succeeds.
* m4/closedir.m4 (gl_FUNC_CLOSEDIR): Replace if
with dirp to
dirp_fd_list.
(_gl_unregister_dirp_fd): New. Unregister fd with closing it.
(dirfd): Implemented for kLIBC.
* lib/fdopendir.c (fdopendir): Implemented for kLIBC.
* lib/opendir.c (opendir): New. Register fd and dirp pair if open()
succeeds.
* m4/closedir.m4 (gl_FUNC_CLOSEDIR): Replace if
KO Myung-Hun wrote:
>
> 0001-opendir-closedir-dirfd-fdopendir-port-to-OS-2-kLIBC.patch
>
Updated.
--
KO Myung-Hun
Using Mozilla SeaMonkey 2.7.2
Under OS/2 Warp 4 for Korean with FixPak #15
In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM
Korean OS/2 User Communi
473f232c1565ff8c84dae94a9b8ef958a941 Mon Sep 17 00:00:00 2001
From: KO Myung-Hun
Date: Fri, 28 Nov 2014 16:47:12 +0900
Subject: [PATCH] opendir, closedir, dirfd, fdopendir: port to OS/2 kLIBC
* lib/closedir.c (closedir): Unregister fd if closedir() succeeds.
* lib/dirent.h.in (_gl_register_dirp
Paul Eggert wrote:
> KO Myung-Hun wrote:
>> I want to do later separately. No ?
>
> You could put it in a later patch, I suppose, but I wouldn't want to
> install this patch without also installing the later patch.
Ok. I'll try later.
--
KO Myung-Hun
Using Mozilla SeaMonkey 2.7.2
Under OS/2
KO Myung-Hun wrote:
I want to do later separately. No ?
You could put it in a later patch, I suppose, but I wouldn't want to install
this patch without also installing the later patch.
Hi/2.
Paul Eggert wrote:
> KO Myung-Hun wrote:
>> /* FIXME: close() fd explicitly after closedir(), or fd leaks */
>> +
>
> This needs to be fixed. Can't you override closedir?
Possible. But I want to do later separately. No ?
--
KO Myung-Hun
Using Mozilla SeaMonkey 2.7.2
Under OS/2 Warp 4 f
KO Myung-Hun wrote:
/* FIXME: close() fd explicitly after closedir(), or fd leaks */
+
This needs to be fixed. Can't you override closedir?
r Korean with FixPak #15
In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM
Korean OS/2 User Community : http://www.ecomstation.co.kr
From 5edee471f3e45d962c6112e29ceaeadd1d3e902b Mon Sep 17 00:00:00 2001
From: KO Myung-Hun
Date: Fri, 28 Nov 2014 16:47:12 +0900
Subject: [PAT
On 12/01/2014 11:49 PM, KO Myung-Hun wrote:
First, we don't have copyright assignment from Paul Smedley, so we can't
install the patch without having that cleared up one way or another.
Which ways ?
Either get a copyright assignment from Smedley, or rewrite the change
from scratch without us
Hi/2.
Paul Eggert wrote:
> KO Myung-Hun wrote:
>> * lib/fdopendir.c (fdopendir): Implement on OS/2 kLIBC.
>>
>> Patches from coreutils 8.8 by Paul Smedley.
>
> First, we don't have copyright assignment from Paul Smedley, so we can't
> install the patch w
KO Myung-Hun wrote:
* lib/fdopendir.c (fdopendir): Implement on OS/2 kLIBC.
Patches from coreutils 8.8 by Paul Smedley.
First, we don't have copyright assignment from Paul Smedley, so we can't install
the patch without having that cleared up one way or another.
Second, the patc
* lib/fdopendir.c (fdopendir): Implement on OS/2 kLIBC.
Patches from coreutils 8.8 by Paul Smedley.
---
lib/fdopendir.c | 57 +
1 file changed, 57 insertions(+)
diff --git a/lib/fdopendir.c b/lib/fdopendir.c
index b6c94a0..efe9c7a 100644
* modules/fts (Depends-on): Depend on fdopendir. This is needed
on Solaris 8, at least, since it lacks fdopendir. Evidently the
problem was introduced when fdopendir was split out.
---
ChangeLog |7 +++
modules/fts |1 +
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git
FreeBSD fdopendir(fd) always consumes fd, even if it fails with
ENOTDIR. The code that works around the GNU Hurd bug also fixes this;
we just need to detect it.
* m4/fdopendir.m4 (gl_FUNC_FDOPENDIR): Detect bug.
* doc/posix-functions/fdopendir.texi (fdopendir): Document it.
Reported by Jim
directory stream. */
>> fd = open ("test-fdopendir.tmp", O_RDONLY | O_CREAT, 0600);
>> ASSERT (0 <= fd);
>> errno = 0;
>> ASSERT (fdopendir (fd) == NULL);
>> ASSERT (errno == ENOTDIR);
>> ASSERT (close (fd) == 0);
>> ...
>>
>>
ndir.tmp", O_RDONLY | O_CREAT, 0600);
> ASSERT (0 <= fd);
> errno = 0;
> ASSERT (fdopendir (fd) == NULL);
> ASSERT (errno == ENOTDIR);
> ASSERT (close (fd) == 0);
> ...
>
> because the close returns nonzero.
> It sets errno to EBADF.
>
> It'
Given this code from test-fdopendir.c, FreeBSD 8.1 fails
int
main (void)
{
DIR *d;
int fd;
/* A non-directory cannot be turned into a directory stream. */
fd = open ("test-fdopendir.tmp", O_RDONLY | O_CREAT, 0600);
ASSERT (0 <= fd);
errno = 0;
ASSERT (fdopendir
On 11/08/2010 05:38 AM, tsteven4 wrote:
> The revised fdopendir.c you sent resolved the tar-1.25 test issue with test
> 37:
Thanks, I pushed that gnulib patch as:
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=bc2e836273a27da04e43c5ffada54f567aa35980
The other tar failure is st
25_dtruss.txt" while running "make check TESTSUITEFLAGS=37".
Thanks for sending that. In looking through the dtruss output I see a
bug in gnulib's fdopendir.c implementation: when fdopendir(N) is
invoked, and N is the maximum openable file descriptor, and there are
some unop
through the dtruss output I see a
bug in gnulib's fdopendir.c implementation: when fdopendir(N) is
invoked, and N is the maximum openable file descriptor, and there are
some unopened file descriptors less than N, then fdopendir first uses
'dup' to consume these unopened file descrip
This follows up on the thread earlier today. In testing my earlier
patch, I found that fdopendir (FD) didn't do the right thing when
FD was the maximum allowed file descriptor but lower-numbered file
descriptors were available: it failed with errno == EMFILE. I pushed
the following patch in
On 09/12/2010 04:18 PM, Paul Eggert wrote:
While coding up recent changes to GNU tar, I discovered a
POSIX-emulation problem in gnulib's implementation of fdopendir.
I had written code like this:
DIR *dp = fdopendir (fd);
int fd1 = openat (fd, "subdir", O_RDONL
While coding up recent changes to GNU tar, I discovered a
POSIX-emulation problem in gnulib's implementation of fdopendir.
I had written code like this:
DIR *dp = fdopendir (fd);
int fd1 = openat (fd, "subdir", O_RDONLY);
This works with POSIX fdopendir, but the gnu
(fdopendir): Supply missing FreeBSD
declaration.
* doc/posix-functions/fdopendir.texi (fdopendir): Document the
fix.
Reported by Christian Weisgerber .
Signed-off-by: Eric Blake
---
Now pushed, with fdopendir.m4 tweaked appropriately. I also tested
on Linux with dirent.h temporarily modified to not
[re-adding the list]
On 03/29/2010 04:39 PM, Christian Weisgerber wrote:
>> I'm still trying to get access to a FreeBSD 7 box to test this out
>> myself (my current FreeBSD access is running 8.0, but that does not
>> have the bug).
>
> Well, you can temporarily remov
(fdopendir): Supply missing FreeBSD
declaration.
* doc/posix-functions/fdopendir.texi (fdopendir): Document the
fix.
Reported by Christian Weisgerber .
Signed-off-by: Eric Blake
---
I'm still trying to get access to a FreeBSD 7 box to test this out
myself (my current FreeBSD access is running 8.0
I noticed (by accident) that a typo in fdopendir was rejecting working
implementations. Pushing:
--
Don't work too hard, make some time for fun as well!
Eric Blake e...@byu.net
From e138cd8fc9c9465059e9d0427d0cf0669d5a8caf Mon Sep 17 00:00:00 2001
From: Eric Blake
Date: Mon,
mistakenly assumes if openat() is available, so will be
| fdopendir(). FreeBSD imported the Solaris-style *at() functions,
| but it does not have fdopendir(), and I don't see how the existence
| of the one should imply the existence of the other.
|
| Apparently the problematic code is shared acros
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Geoff Clare on 6/21/2007 2:42 AM:
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote, on 20 Jun 2007:
>> @ page 797 line 27082 section fdopendir objection {ebb.fdopendir}
>>
>> Problem:
>>
>> Line 2701
67 matches
Mail list logo
