Re: Detect UNIX domain sockets supported by recent Windows versions.

Hi Collin, > Perhaps test-sys_un{.c,cc} like usual > and another test program for UNIX socket functionality if or > is found. Yes. > I'm thinking that for older versions of Windows and systems without UNIX > sockets they should all be skipped. > > I don'

Re: Detect UNIX domain sockets supported by recent Windows versions.

ns of Windows and systems without UNIX sockets they should all be skipped. I don't think there is much point in defining 'struct sockaddr_un' if AF_UNIX is not supported. Maybe the tests should all be like: #if HAVE_UNIXSOCKET int main () { /* Do test. */ } #else int main { /*

Re: Detect UNIX domain sockets supported by recent Windows versions.

Hi Collin, > I'll write a sys_un module to deal with including afunix.h tomorrow. Nice! And a unit test would be nice as well. You know, it's only through the unit tests that we discover the portability problems. I think such a unit test shouldn't use fork(), like tests/test-passfd.c does, sinc

Detect UNIX domain sockets supported by recent Windows versions.

le to deal with including afunix.h tomorrow. Collin [1] https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/ >From d3efdd55f36a01118ed936da25633858a5757897 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Tue, 23 Jul 2024 21:31:06 -0700 Subject: [PATCH] Detect UNIX domain so

[PATCH] socketlib, sockets, sys_socket: Use AC_REQUIRE to pacify autoconf.

Without this change, in bleeding-edge fileutils Autoconf complains that gl_SOCKETLIB etc. are AC_REQUIREd after being invoked. * modules/socketlib (configure.ac): AC_REQUIRE gl_SOCKETLIB. * modules/sockets (configure.ac): AC_REQUIRE gl_SOCKETS. * modules/sys_socket (configure.ac): AC_REQUIRE

Re: [PATCH 4/9] sockets, sys_stat: remove AC_C_INLINE in MSVC-only cases

Hi Paul, > Anyway, I reverted that change. Thanks. Bruno

Re: [PATCH 4/9] sockets, sys_stat: remove AC_C_INLINE in MSVC-only cases

On Sun, Sep 30, 2012 at 7:24 PM, Paul Eggert wrote: > On 09/30/2012 03:22 PM, Bruno Haible wrote: > > Nope. MSVC does *not* support 'inline' for functions. > > Thanks for catching that. Sorry, I thought they > supported it, it's been in the standard for what, > 12 years now? > Unfortunately, MS

Re: [PATCH 4/9] sockets, sys_stat: remove AC_C_INLINE in MSVC-only cases

On 09/30/2012 03:22 PM, Bruno Haible wrote: > Nope. MSVC does *not* support 'inline' for functions. Thanks for catching that. Sorry, I thought they supported it, it's been in the standard for what, 12 years now? Anyway, I reverted that change.

Re: [PATCH 4/9] sockets, sys_stat: remove AC_C_INLINE in MSVC-only cases

Hi Paul, > * m4/sockets.m4 (gl_SOCKETS): > * m4/sys_stat_h.m4 (gl_HEADER_SYS_STAT_H): > Remove AC_C_INLINE. Here, 'inline' is used only in MSVC > environments where it's already guaranteed to work Nope. MSVC does *not* support 'inline' for functions. Quoting

[PATCH 4/9] sockets, sys_stat: remove AC_C_INLINE in MSVC-only cases

m4/sockets.m4| 3 +-- m4/sys_stat_h.m4 | 5 + 3 files changed, 11 insertions(+), 6 deletions(-) diff --git a/ChangeLog b/ChangeLog index 5f8f5c7..3124aa3 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2012-08-29 Paul Eggert + + sockets, sys_stat: remove AC_C_INLINE i

fcntl and sockets on mingw

In a gnulib testdir for the modules accept accept4 fcntl socket I'm seeing this compilation error on mingw: gcc-3 -mno-cygwin -g -O2 -L/usr/local/mingw/lib -o test-fcntl.exe test-fcntl.o libtests.a ../gllib/libgnu.a libtests.a ../gllib/libgnu.a(fcntl.o): In function `dupfd': /home/bruno/mul

Re: [PATCH 2/4] sendfd, recvf pass file descriptors along Unix domain sockets

Hi Bastien, > lib/passfd.c | 147 > > lib/passfd.h | 21 > modules/passfd | 30 +++ This code looked nearly fine as well (at least superficially), so I've committed it in your name with this ChangeLog entry: 2011

Re: [PATCH 2/3] sendfd, recvf pass file descriptors along Unix domain sockets

On 03/06/2011 02:43 AM, Bastien ROUCARIES wrote: > Le jeudi 3 mars 2011 22:33:21, Eric Blake a écrit : >> On 03/01/2011 07:04 AM, Bastien ROUCARIES wrote: >>> Recvfd and sendfd can be used to pass an open file descriptor over a Unix >>> domain socket from one process to another. >> >> >> Again, mem

[PATCH 2/4] sendfd, recvf pass file descriptors along Unix domain sockets

Recvfd and sendfd can be used to pass an open file descriptor over a Unix domain socket from one process to another. --- lib/passfd.c | 147 lib/passfd.h | 21 modules/passfd | 30 +++ 3 files changed, 198 insertio

Re: [PATCH 2/3] sendfd, recvf pass file descriptors along Unix domain sockets

Le jeudi 3 mars 2011 22:33:21, Eric Blake a écrit : > On 03/01/2011 07:04 AM, Bastien ROUCARIES wrote: > > Recvfd and sendfd can be used to pass an open file descriptor over a Unix > > domain socket from one process to another. > > > Again, memcpy, not type-punning. How can I run test using memc

Re: [PATCH 2/3] sendfd, recvf pass file descriptors along Unix domain sockets

Le jeudi 3 mars 2011 22:33:21, Eric Blake a écrit : > On 03/01/2011 07:04 AM, Bastien ROUCARIES wrote: > > Recvfd and sendfd can be used to pass an open file descriptor over a Unix > > domain socket from one process to another. > > Have you considered porting this to Windows yet? I like the idea

Re: [PATCH 2/3] sendfd, recvf pass file descriptors along Unix domain sockets

On 03/03/2011 10:33 PM, Eric Blake wrote: I just createdhttp://sourceware.org/bugzilla/show_bug.cgi?id=12539 - it would be nice if the kernel and glibc would give us a way to atomically set the FD_CLOEXEC flag on fd's created by recvfd. But even without atomic support from the kernel, it would

Re: [PATCH 2/3] sendfd, recvf pass file descriptors along Unix domain sockets

On 03/01/2011 07:04 AM, Bastien ROUCARIES wrote: > Recvfd and sendfd can be used to pass an open file descriptor over a Unix > domain socket from one process to another. Have you considered porting this to Windows yet? I like the idea of this module (especially since I want to use it in libvirt)

[PATCH 2/3] sendfd, recvf pass file descriptors along Unix domain sockets

Recvfd and sendfd can be used to pass an open file descriptor over a Unix domain socket from one process to another. --- lib/passfd.c | 145 lib/passfd.h | 21 modules/passfd | 28 +++ 3 files changed, 194 insertio

[PATCH 2/3] sendfd, recvf pass file descriptors along Unix domain sockets

Recvfd and sendfd can be used to pass an open file descriptor over a Unix domain socket from one process to another. --- lib/passfd.c | 143 lib/passfd.h | 22 + modules/passfd | 28 +++ 3 files changed, 193 inserti

Re: [PATCH 2/3] sendfd, recvf pass file descriptors along Unix domain sockets

Le mercredi 2 février 2011 16:45:08, Eric Blake a écrit : > On 02/02/2011 07:33 AM, Bastien ROUCARIES wrote: > > Recvfd and sendfd can be used to pass an open file descriptor over a Unix > > domain socket from one process to another. > > Not on cygwin. I don't know of any way that you can port th

Re: [PATCH 2/3] sendfd, recvf pass file descriptors along Unix domain sockets

On 02/02/2011 07:33 AM, Bastien ROUCARIES wrote: > Recvfd and sendfd can be used to pass an open file descriptor over a Unix > domain socket from one process to another. Not on cygwin. I don't know of any way that you can port this to cygwin, which means use of this module inherently restricts y

[PATCH 2/3] sendfd, recvf pass file descriptors along Unix domain sockets

Recvfd and sendfd can be used to pass an open file descriptor over a Unix domain socket from one process to another. --- lib/passfd.c | 143 lib/passfd.h | 22 + modules/passfd | 28 +++ 3 files changed, 193 inserti

[PATCH] getaddrinfo: Initialize sockets, to make it work under Windows.

The getaddrinfo replacement didn't work on Windows if the application hadn't already initialized sockets. I believe replacement socket functions should call WSAStartup on Windows -- POSIX doesn't require any socket initialization code, and other gnulib replacement functions (e.g.,

Re: test-sockets compilation

Eric Blake writes: > Is it okay to commit this, to silence a gcc warning about a statement with no > effect on non-mingw systems? Please do. /Simon

test-sockets compilation

Is it okay to commit this, to silence a gcc warning about a statement with no effect on non-mingw systems? From: Eric Blake Date: Wed, 25 Mar 2009 09:35:18 -0600 Subject: [PATCH] test-sockets: avoid gcc warning * tests/test-sockets.c (main): Silence compiler warning. Signed-off-by: Eric

sockets: make LGPLv2+

I needed sockets in gnutls. Pushed. /Simon >From d51f43cc57c6e7d25ab44ce188af157642900720 Mon Sep 17 00:00:00 2001 From: Simon Josefsson <[EMAIL PROTECTED]> Date: Thu, 30 Oct 2008 20:57:32 +0100 Subject: [PATCH] modules/sockets (License): Change from LGPL to LGPLv2+. ---

Re: sockets module and Solaris

> *** modules/poll-tests.orig 2008-09-29 11:32:59.0 +0200 > --- modules/poll-tests2008-09-29 11:32:45.0 +0200 > *** > *** 18,20 > --- 18,21 > Makefile.am: > TESTS += test-poll > check_PROGRAMS += test-poll > + test_poll_LDADD = $(LDADD) @LIBSOC

Re: sockets module and Solaris

> *** modules/sys_select-tests.orig 2008-09-28 20:36:59.0 +0200 > --- modules/sys_select-tests 2008-09-28 19:43:06.0 +0200 > *** > *** 16,21 > --- 16,22 > Makefile.am: > TESTS += test-sys_select > check_PROGRAMS += test-sys_select > + test_sys_selec

Re: sockets module and Solaris

articular not for test-sys_select or test-sockets. The relevant symbol list of libnsl (taken from http://www.haible.de/bruno/gnu/various-symlists.tar.gz): auth* clnt* endhostent endnetconfig endnetpath endrpcent freehostent freeipsecalgent freenetconfigent get_myaddress getdomainname gethostbyadd

Re: sockets module and Solaris

Bruno Haible <[EMAIL PROTECTED]> writes: > Hi Simon, > > Here are two change requests regarding the 'sockets' module: > > 1) Currently it adds the library option -lws2_32 to LIBS. But I don't want >to link all gettext tools against this libray, just be

sockets module and Solaris

Hi Simon, Here are two change requests regarding the 'sockets' module: 1) Currently it adds the library option -lws2_32 to LIBS. But I don't want to link all gettext tools against this libray, just because one program (test-sys_select) needs to link with it. So I propose

Re: sockets

Eric Blake <[EMAIL PROTECTED]> writes: > According to Simon Josefsson on 1/24/2008 7:58 AM: > | Since there weren't any other comments after close to a week, and the > | 'sockets' module doesn't affect anyone that isn't strictly using it, I > | have com

Re: sockets

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Simon Josefsson on 1/24/2008 7:58 AM: | Since there weren't any other comments after close to a week, and the | 'sockets' module doesn't affect anyone that isn't strictly using it, I | have committed the patch

Re: sockets

Simon Josefsson wrote: > Thanks for testing. I think the test "just happens" to fail under > cygwin, but as long as that is always consistent, I think that is fine. In a sense, HAVE_WINSOCK2_H=0 is in fact correct on Cygwin. Even though the header is available it's not correct to include it in

Re: sockets

Brian Dessent <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: > >> continue to work under cygwin. Btw, could you quote the part from >> config.log which explains _why_ the m4 macro fails under cygwin? It >> isn't clear from the M4 check that it would fail under cygwin, but maybe >> it is ju

Re: sockets

Simon Josefsson wrote: > continue to work under cygwin. Btw, could you quote the part from > config.log which explains _why_ the m4 macro fails under cygwin? It > isn't clear from the M4 check that it would fail under cygwin, but maybe > it is just my lack of knowledge with cygwin. Still, if it

Re: sockets

ild/gltests/../../gltests/test-sockets.c:29: > undefined reference to `_gl_sockets_startup' > /home/eblake/gnulib/testdir2736/build/gltests/../../gltests/test-sockets.c:36: > undefined reference to `_gl_sockets_cleanup' > collect2: ld returned 1 exit status > > Were you intending that

Re: sockets

ib/testdir2736/build/gltests/../../gltests/test-sockets.c:36: undefined reference to `_gl_sockets_cleanup' collect2: ld returned 1 exit status Were you intending that all apps using sockets call gl_sockets_{start,clean}up (in which case, you need to declare them, perhaps as a no-op define, for non-

sockets

tup=no) LIBS="$am_save_LIBS"]) if test "$gl_cv_func_wsastartup" = "yes"; then LIBS="$LIBS -lws2_32" AC_LIBOBJ(sockets) gl_PREREQ_SOCKETS fi ]) # Prerequisites of lib/sockets.c. AC_DEFUN([gl_PREREQ_SOCKETS], [ : ]) /* sockets.h - wrappe

Re: mingw32 and sockets

API without effort. > > Do you like that? Or better pure POSIX? I think the above would be sufficient. My GNU SASL tool uses the same read/write for both sockets and stdin/stdout, so I would have to rewrite it slightly. But I don't need this functionality right now, so I don't want

Re: mingw32 and sockets

On Tuesday 27 September 2005 18:03, Derek Price wrote: > Ingolf Steinbach wrote: > >I have done a select() emulation on Win32 once. It was horrible. > I don't suppose the implementation was GPL'd or LGPL'd or could be? Sorry, it was part of a closed-source software project developed for the German

RE: mingw32 and sockets

d be nice, but I'm not sure how to do > it without wrapping nearly all the low-level IO routines like Cygwin did. In a prior message I suggested wrapping Microsft C Run Time (CRT) functions to expose the Win32 API number space but it can go the other direction. Wrapping the Windows Socket

Re: mingw32 and sockets

Conrad T. Pino wrote: >I suggest avoiding "wnt_select" in favor of either "wnt_fd_select" or >"woe32_fd_select" instead. > > I prefer woe32_fd_select, but you're writing it and I'm not that picky. :) >Wrapping the Windows Socket API to

Re: mingw32 and sockets

Ingolf Steinbach wrote: > I have done a select() emulation on Win32 once. It was horrible. > If you want to avoid multithreading ... Things get simpler if you accept the need to create new threads on Woe32. Another example of this is that if you want to handle Ctrl-C gracefully (i.e. do something

Re: mingw32 and sockets

Ingolf Steinbach wrote: >I have done a select() emulation on Win32 once. It was horrible. > I don't suppose the implementation was GPL'd or LGPL'd or could be? >And maybe the situation is easier for CVS when the communication >can be reduced to pipes and sock

Re: mingw32 and sockets

Hi, On Tuesday 27 September 2005 16:42, Derek Price wrote: > Actually, Windows select() works _only_ on sockets. Select on other fds > returns "WSAENOTSOCK". > > bug-cvs@nongnu.org has recently been discussion a select() wrapper that > could tell the difference for

Re: mingw32 and sockets

e(), select(), poll() don't work on sockets. But the Woe32 API >offers equivalents under different names. > > Actually, Windows select() works _only_ on sockets. Select on other fds returns "WSAENOTSOCK". bug-cvs@nongnu.org has recently been discussion a sel

Re: mingw32 and sockets

gnulib. The Woe32 socket API has three main differences w.r.t. the POSIX socket API: - The type of a socket is 'SOCKET', not 'int'. A SOCKET cannot be used in places where a file descriptor is used. This means in particular that close(), select(), poll() don't wo

Re: mingw32 and sockets

Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> Would it be possible to create those three POSIX header files if they >> don't exist on the system, and if winsock2.h do exist? The created >> files would simply #include . > > Yes, that's the way I would go. It seems doing tha

Re: [bug-gnulib] mingw32 and sockets

Simon Josefsson wrote: > Would it be possible to create those three POSIX header files if they > don't exist on the system, and if winsock2.h do exist? The created > files would simply #include . Yes, that's the way I would go. > Creating them would be done > like getopt_.h and others. The comp

Re: mingw32 and sockets

John Vandenberg <[EMAIL PROTECTED]> writes: > On 9/22/05, Simon Josefsson <[EMAIL PROTECTED]> wrote: >> Mingw32 doesn't have sys/types.h, arpa/inet.h or netinet/in.h. But if >> you include winsock2.h instead of those three header files, most (?) >> POSIX socket functions work. > > I doubt that an

Re: mingw32 and sockets

Paul Eggert <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> writes: > >> Mingw32 doesn't have sys/types.h, > > Ouch. Lots of gnulib code assumes that sys/types.h exists and works. > (The only exception is the socklen module itself.) Sorry, I meant sys/socket.h. __

Re: mingw32 and sockets

On 9/22/05, Simon Josefsson <[EMAIL PROTECTED]> wrote: > Mingw32 doesn't have sys/types.h, arpa/inet.h or netinet/in.h. But if > you include winsock2.h instead of those three header files, most (?) > POSIX socket functions work. I doubt that any POSIX socket functions in winsock2 will conform to

Re: mingw32 and sockets

Simon Josefsson <[EMAIL PROTECTED]> writes: > Mingw32 doesn't have sys/types.h, Ouch. Lots of gnulib code assumes that sys/types.h exists and works. (The only exception is the socklen module itself.) > Perhaps this should be considered a mingw32 bug instead? I would. Google reports that other

mingw32 and sockets

Mingw32 doesn't have sys/types.h, arpa/inet.h or netinet/in.h. But if you include winsock2.h instead of those three header files, most (?) POSIX socket functions work. The simplest solutions would be to replace: #include #include #include with: #include "glsocket.h" or something, and glsoc