Re: glob.c and MSVC

2015-02-24 Thread Paul Eggert
How about the attached patch instead? >From f386f157997182fa54c5ff408233f42a3ef6d0ed Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 24 Feb 2015 20:44:32 -0800 Subject: [PATCH] glob, etc.: port to MSVC v18 on MS-Windows 8.1 * lib/dirent--.h (GNULIB_defined_opendir): * lib/dirent.in.h (GNUL

Re: glob.c and MSVC

2015-02-24 Thread Gisle Vanem
Paul Eggert wrote 22-Jan-2015: diff --git a/ChangeLog b/ChangeLog index e0c12d3..8839306 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2015-01-21 Paul Eggert + + getcwd, glob, scandir: port to MSVC + Problem reported by Gisle Vanem in: + http://lists.gnu.org/archive

Re: poll.c on Windows

2015-02-24 Thread Paul Eggert
Thanks for the report. How about the attached patch instead? I've pushed it. >From 79aeac1a022daa372715ffbbc2bff641569acfb5 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 24 Feb 2015 16:16:19 -0800 Subject: [PATCH] poll: port to MSVC v18 on MS-Windows 8.1 Problem reported by Gisle Vanem

Re: gettext vs. gnulib m4 macros

2015-02-24 Thread Paul Eggert
Karl Berry wrote: So now my question is, are all of the *.m4 files in gettext-runtime/m4 really maintained in gettext? No, for some of those files (e.g., m4/extern-inline.m4), gettext copied the files from gnulib, and gnulib has always been the primary location for them. For others of those f

Re: gettext vs. gnulib m4 macros

2015-02-24 Thread Karl Berry
I agree with adding them to srclist.txt Ok, thanks. Sounds good, I will. So now my question is, are all of the *.m4 files in gettext-runtime/m4 really maintained in gettext? I.e., they should all be added to srclist.txt? $ ls gettext-0.19.4/gettext-runtime/m4/ ChangeLog gettext.m4

poll.c on Windows

2015-02-24 Thread Gisle Vanem
I'm getting this error at the link stage (MSVC v18 on Win-8.1): poll.obj : error LNK2019: unresolved external symbol _recv_used_without_including_sys_socket_h referenced in function _windows_compute_revents_socket poll.obj : error LNK2019: unresolved external symbol _select_used_wit

[PATCH] tests: support stderr verification with returns_()

2015-02-24 Thread Pádraig Brady
* tests/init.sh (returns_): Disable tracing for this wrapper function, so that stderr of the wrapped command is unchanged, allowing for verification of the contents. --- ChangeLog | 7 +++ tests/init.sh | 10 +- 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/Change

Re: [PATCH] passfd: fix use of uninitialised variable

2015-02-24 Thread Pavel Hrdina
On Tue, Feb 24, 2015 at 12:17:19PM +, Pádraig Brady wrote: > On 24/02/15 10:14, Pavel Hrdina wrote: > > This was found by running libvirt using valgrind. Commit ee195daf > > introduced passfd code. > > > > ==7533== Syscall param sendmsg(msg.msg_control) points to uninitialised > > byte(s) > >

Re: [PATCH] passfd: fix use of uninitialised variable

2015-02-24 Thread Pádraig Brady
On 24/02/15 10:14, Pavel Hrdina wrote: > This was found by running libvirt using valgrind. Commit ee195daf > introduced passfd code. > > ==7533== Syscall param sendmsg(msg.msg_control) points to uninitialised > byte(s) > ==7533==at 0x8C728FD: ??? (in /lib64/libpthread-2.19.so) > ==7533==b

[PATCH] passfd: fix use of uninitialised variable

2015-02-24 Thread Pavel Hrdina
This was found by running libvirt using valgrind. Commit ee195daf introduced passfd code. ==7533== Syscall param sendmsg(msg.msg_control) points to uninitialised byte(s) ==7533==at 0x8C728FD: ??? (in /lib64/libpthread-2.19.so) ==7533==by 0x54F04D1: sendfd (passfd.c:86) ==7533==by 0x543