[PATCH 3/3] Add a native win32 implementation of poll

Finally, this one works. The previous version worked on Wine but not on native Win32 because of a difference in how WSAEnumNetworkEvents works. The Win32 manual is clear that calling WSAEnumNetworkEvents *clears* the events until a further system call is issued (the system call is recv/read for F

[PATCH 2/3] add winsock wrappers

There are two changes compared to previous versions of the patch: 1) The socket wrapper calls WSASocket to return a "non-overlapped" socket. Overlapped sockets cannot be read and written with read/write (i.e. Win32 API functions ReadFile/WriteFile), only with ReadFileEx/WriteFileEx -- besides rec

[PATCH 1/3] downgrade minimum winsock version necessary for test-poll

It turns out that 1.1 is enough, and the HP TestDrive machine(*) fail if you pass SOCKETS_2_0. (*) Interesting that they give only a Win64 cross-compiler on a Win32 machine, so that you have to cross-compile on Linux and move the executable there... I'll commit this together with the others

Re: mingw fopen bug

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 9/22/2008 6:15 PM: > But fopen() on a directory? Who does that? If no-one needs that, I would be > satisfied with mentioning the problem under "Portability problems not fixed by > Gnulib" in the doc. The use case where I d

Re: mingw fopen bug

Hi Eric, Eric Blake wrote: > Adding such a workaround would allow code like this to work on mingw: > > FILE *f = fopen (".", "r"); > DIR *d = fdopendir (fileno (f)); > readdir (d); I understand the heavy use of fdopendir() in coreutils: on those systems which implement this function natively, it

Re: test-vsprintf-posix: make check failure

Hi Eric, > Like so. Bruno, okay to apply? Thanks for the analysis. The patch is nearly perfect. Only the change of the 'precision' variable from 6 to 0 comes a bit too late: by this time, its value 6 has already been used for computing the size of a memory allocation. (I.e. it would allocates mo

mingw fopen bug

According to POSIX, open(".",O_RDONLY) must succeed. And if I'm reading POSIX correctly, fopen(".","r") must also succeed, since it should have the same effect as open(".",O_RDONLY). It is only on subsequent attempts to read() from a directory that POSIX then allows, but not requires, a failur

Re: test-vsprintf-posix: make check failure

Eric Blake byu.net> writes: > It looks like the solution is to also add > support at line 3149 (for long double) for the %a format Like so. Bruno, okay to apply? (gmane probably botched this patch, so you can also see it at http://repo.or.cz/w/gnulib/ericb.git?a=shortlog;h=refs/heads/vasnpri

Re: test-vsprintf-posix: make check failure

Simon Josefsson josefsson.org> writes: > > FYI, this fails on a vanilla debian x86 testing system: > > gnulib-tool --with-tests --test vsprintf-posix > > Here is the debug backlog: > I'm seeing it too; it comes from an attempt to call vasnprintf("%Ld", 0.0L). It stems from the fact that th

poll-for-win32 merge ready

Hi all, I managed to test the poll-for-win32 branch on win32. The passing tests are the same as cygwin. I'll send patches tomorrow. In the meanwhile, the code is at db8076e3e8778c7d5fab9d4ccbc73a05860ce6f3 on Eric's mob branch [EMAIL PROTECTED]:/srv/git/gnulib/ericb.git ciao, Paolo

Module request: wordexp

Would be great to get wordexp into gnulib. OS X 10.4 finally has it, but it's incompletely implemented (the flags are ignored), so it's easy to *think* you're getting something ported when in fact it may not work correctly. OS X 10.5 claims to have the flags implemented, but there is an apparent bu

Re: c-stack and Irix - libsigsegv

On Mon, Sep 22, 2008 at 12:01:23AM +0200, Bruno Haible wrote: > Tom G. Christensen wrote: > > cc-3316 cc: ERROR File = handler-unix.c, Line = 490 > > The expression must be a pointer to a complete object type. > > > > ss.ss_sp = extra_stack + extra_stack_size - sizeof (void *); > >

Re: Issue with ls -v / sort -V and strverscmp() usage

On Monday 22 September 2008 14:36:02 Eric Blake wrote: > On the other hand, the fact that strverscmp provides a distinction based > on leading zeros is nice, as it guarantees a stable sort (no two strings > that differ on strcmp will compare equal with strverscmp). Good point, thanks. The function

Re: Issue with ls -v / sort -V and strverscmp() usage

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 9/22/2008 6:21 AM: > Kamil, you may expect to use the new function in ls, too. > The more I think of this, the more I'm convinced producing > sensible results is what matters here. Being completely > compatible with older

Re: Issue with ls -v / sort -V and strverscmp() usage

Bruno Haible <[EMAIL PROTECTED]> wrote: > Hi Kamil, >> New version of filevercmp.c is attached, now without copying of the input >> strings. I've also made a simple performance test - the speed was about 7-8x >> slower than original glibc strverscmp function, but the glibc's result is >> mostly wro

test-vsprintf-posix: make check failure

FYI, this fails on a vanilla debian x86 testing system: gnulib-tool --with-tests --test vsprintf-posix Here is the debug backlog: [EMAIL PROTECTED]:~/src/gnulib/testdir12690/build/gltests master$ gdb ./test-vsprintf-posix GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. Lic

Re: msgmerge speedup: fstrcmp and diffseq improvements

Hello Ralf, Ralf Wildenhues wrote: > BTW, I now found a newer paper that has some more interesting stuff, if > a bit overkill for msgmerge: . > Also, there is this good overview of algorithms: > .