Re: [bug-gnulib] poll(2) emulation doesn't work well on a file descriptor

Bruno Haible wrote: Daiki Ueno wrote: When I tried a tiny program which uses gnulib's poll(2) emulation on MacOS X 10.4, I found a bug. gnulib's poll(2) uses recv(2) with MSG_PEEK to support POLLHUP. However, recv(2) is only applicable to a socket, not to a file descriptor. It's much w

Updates to poll module

implementation of kqueue, and hence poll, for non-socket descriptors too), but my guess that not all Mac users will upgrade... Ok? Paolo 2006-09-27 Paolo Bonzini <[EMAIL PROTECTED]> * m4/poll.m4: Test for sys/ioctl.h and sys/filio.h. * lib/poll.c (poll) [__APPLE__]: Use FIONREAD i

Make gnulib-tool --update less verbose

$,/,p'` -sourcebase_base=`basename "$sourcebase"` -echo " - mention \"${sourcebase_base}\" in SUBDIRS in ${sourcebase_dir}Makefile.am," - fi - if test -n "$inctests"; then -if test "$makefile_am" = Makefile.am; then - testsbas

Re: Make gnulib-tool --update less verbose

ot;` - echo " - mention \"${testsbase_base}\" in SUBDIRS in ${testsbase_dir}Makefile.am," +func_echo_header " - mention \"${testsbase_base}\" in SUBDIRS in ${testsbase_dir}Makefile.am," + fi + fi fi + if test -z "$cached_specif

Re: Updates to poll module

* m4/poll.m4: Test for sys/ioctl.h and sys/filio.h. * lib/poll.c (poll) [__APPLE__]: Use FIONREAD instead of MSG_PEEK. Looks reasonable to me. But you don't need our permission to install; you're the maintainer. I don't have CVS access to gnulib; anyway I preferred to

Re: [bug-gnulib] Updates to poll module

+ do + r = ioctl (pfd[i].fd, FIONREAD, &avail); + while (r == -1 && (errno == EAGAIN || errno == EINTR)); + if (avail < 0) + avail = 0; When ioctl returns -1, maybe because FIONREAD is not supported or so, this loops endlessl

[PATCH] fix quotearg when wchar.h is not used

ly on single-byte locales, but a mbstate_t variable is defined around line 420. Fixed with the attached trivial patch. Paolo 2006-10-02 Paolo Bonzini <[EMAIL PROTECTED]> (tiny change) * lib/quotearg.c [!HAVE_MBRTOWC]: Define mbstate_t to int. --- ../gnulib/lib/quotearg.c2006-

replacement poll does not return POLLIN if `accept' is possible on Mac OS X

The attached patch fixes poll to return POLLIN if an accept is possible. A much better fix would have been to use SO_ACCEPTCONN, but due to a bug in the kernel it is not possible to read this option from user mode. Will apply if nobody complains in a couple of days. Paolo 2006-11-29 Paolo

Re: [PATCH]: multiple problem with the poll module

I have been experiencing several problem with the poll module, especially under MacOS X. I was about to submit a patch for poll to fix some of these issues, but I prefer yours much more if it works. In fact, the FIONREAD ioctl is a hack and my patch added yet another hack instead of using t

Re: GCC optimizes integer overflow: bug or feature?

By the way, as I've tried to describe here: variable range tracking can result in reintroduction of supposedly-fixed security vulnerabilities. 8-( Interesting read. I agree with the proposed fix; however, note that GCC does not

Re: GCC optimizes integer overflow: bug or feature?

We've optimized expressions such as (a*2)/2 on the basis of overflow being undefined for a very long time, not just loops. What is (a*2)/2 optimized to? certainly it has the value a if you wrap, so you are not necessarily depending on undefined here. No, it has not. For example, if a is 0x

Re: [PATCH]: multiple problem with the poll module

Yoann Vandoorselaere wrote: Le mardi 19 décembre 2006 à 09:52 -0800, Paul Eggert a écrit : Paolo Bonzini <[EMAIL PROTECTED]> writes: I don't remember if it was Paul or Bruno who suggested that POLLHUP does not increase the return value. What do you think? It wasn't me, s

Re: GCC optimizes integer overflow: bug or feature?

Some time ago (a year?) I was told on this mailing-list that code breakage due to undefinedness of signed overflow is not too common (I at least claimed with no evidence that it was more than one bug per 1,000 lines). My claim was counterclaimed by something like "most of the time people work

Re: GCC optimizes integer overflow: bug or feature?

int j; for (j = 1; 0 < j; j *= 2) if (! bigtime_test (j)) return 1; Here it is obvious to a programmer that the comparison is intended to do overflow checking, even though the test controls the loop. Well, it's not to me. :-) Another question for the GCC expert

Re: GCC optimizes integer overflow: bug or feature?

Or you can do, since elsewhere in the code you compute time_t_max: for (j = 1; j <= time_t_max / 2 + 1; j *= 2) No, this does not work. It would work to have: for (j = 1;;) { if (j > time_t_max / 2) break; j *= 2; } Oops. Paolo

Re: [PATCH]: multiple problem with the poll module

I don't remember if it was Paul or Bruno who suggested that POLLHUP does not increase the return value. What do you think? Attached is an improved version that should conform more to GnuLib coding standard. Hi Yoann, unfortunately the patch is wrong, as it never sets POLLHUP on Mac OS X a

Re: [PATCH]: multiple problem with the poll module

and it does not work, e.g., on file descriptors. Sorry. :-) Could you please provide more information about the problem? (Note that the current CVS version doesn't work on socket, which is not much better). Providing your test case would help. Just open a file, and poll it. It should give

Re: Autoconf manual's coverage of signed integer overflow & portability

The C Standard says that if a program has signed integer overflow its behavior is undefined, and the undefined behavior can even precede the overflow. To take an extreme example: @c Inspired by Robert Dewar's example in @c (2007-01-01). @exampl

Re: Autoconf manual's coverage of signed integer overflow & portability

The C Standard says that if a program has signed integer overflow its behavior is undefined, and the undefined behavior can even precede the overflow. To take an extreme example: @c Inspired by Robert Dewar's example in @c (2007-01-01). @exampl

Re: [PATCH]: multiple problem with the poll module

The previous patch had an issue. Here is an updated version. Ok, here is what I'm going to commit. I simplified a bit the logic to not using ioctl on hosts other than Mac OS X. The patch is -b to simplify reading it. Thanks, Paolo 2007-01-03 Paolo Bonzini <[EMAIL P

no separate javaexec-script module?

gnulib has separate javacomp-script and javacomp module, but no distinction between javaexec-script and javaexec. Does the attached patch to the module description files look correct? Paolo --- modules/javaexec.old2006-09-27 13:39:19.0 +0200 +++ modules/javaexec2007-01-16 08

Re: [PATCH]: Fix poll module under Win32

Yoann Vandoorselaere wrote: Hi, Attached are two small patch fixing poll module compilation under MinGW: - gnulib-poll-depend.diff: Add a dependencies on the sys_select module, fixing inclusion error under MinGW. I committed this part. Paolo

Re: no separate javaexec-script module?

Yes. Except that the license statement should be "GPLed build tool" rather than "GPL" (so that it can be used in LGPLed packages). Okay, I was not sure I could make that change myself. But I'm curious about the use-case: You are in a situation where you want to execute some Java at build/com

wrong permissions on {java,csharp}{comp,exec}.sh

Is the attached patch okay? It is needed to make sure the files are created as executable. Thanks, Paolo 2006-01-17 Paolo Bonzini <[EMAIL PROTECTED]> * modules/csharpcomp-script, modules/csharpexec-script, modules/javacomp-script, modules/javaexec-script: Add ch

Re: wrong permissions on {java,csharp}{comp,exec}.sh

Therefore it's more reliable if you invoke the scripts always with /bin/sh in your Makefiles: /bin/sh javaexec.sh ... And then there is no point in doing "chmod +x". Thanks for the explanation. Paolo

Re: proposed simplification for the 'poll' module

Paul Eggert wrote: Here's a proposed simplification to the 'poll' module to have it use the new sys_time module rather than rolling its own substitute. That's fine by me. Paolo

Re: [PATCH]: fix poll module under win32.

Applied, thanks. Paolo

[Fwd: [PATCH] Fix regex REG_NEWLINE/RE_HAT_LISTS_NOT_NEWLINE (BZ #3957)]

I'm applying this patch to the gnulib CVS. Paolo --- Begin Message --- Hi! RE_HAT_LISTS_NOT_NEWLINE should add \n to [^...] lists, not \0. For build_charclass_op (i.e. \s, \S, \w, \W) only \W might make a difference, but I checked the pre-2002 regex code and \W matched there '\n' no matter wheth

ACL module fails on MacOS X

The sys/acl.h file on MacOS X needs sys/types.h included before it. This patch would fix it, ok to apply? Paolo 2007-02-05 Paolo Bonzini <[EMAIL PROTECTED]> * lib/acl.h: Include sys/types.h before sys/acl.h. Index:

[Fwd: Re: Java-related Bison tests all fail]

We got this report that gt_JAVACOMP([1.3]) does not work for Bison. Can anybody help? Paolo --- Begin Message --- On Fri, 9 Feb 2007, Paolo Bonzini wrote: > > > -gt_JAVACOMP([1.3], [1.3]) > > +gt_JAVACOMP([1.4], [1.4]) > > Can you try instead gt_JAVACOMP([1.3]) -- wi

Re: javacomp.m4 usage [Fwd: Re: Java-related Bison tests all fail]

With Bruno's recent Gnulib patch (working around the old tr bug), the above fixes Java support in Bison for me. Paolo, is this fine with you? Sure it is. Paolo

Re: strcasecmp

Paul Eggert wrote: Bruno Haible <[EMAIL PROTECTED]> writes: It works fine if at least one argument is ASCII _and_ the locale is not a Turkish locale. Thanks for mentioning this. I didn't know that property of Turkish. However, I'm not sure how Turkish people would do lowercase translation

Re: strcasecmp

This consideration points to using (a) c_strcasecmp (a, b) or (b) c_strcasecmp (a, b) || mbscasecmp (a, b). If your Turkish friend says he would write "ırıs", then it points to (b). If not, i.e. if such a word is not considered like a Turkish word, it points to (a). I haven't asked ye

Re: strcasecmp

The only reason for the case-insensitive comparison here is support for Windows-like file names, right? So the issue is not worth our worrying about (except perhaps as a warning that we should avoid case-insensitive comparison whenever we can :-). Not really. It's an option name, and options a

Re: new module 'math'

Bruno Haible wrote: Here's the next "complete" header file, using the same scheme as string.h. Paolo, this changes all the files from the 'mathl' module: - mathl.h is replaced by , - All the .c modules need to include . Not including it is a latent potential trouble. - In some files th

Re: snprintfv for gnulib?

Yes it does. I'm not sure which is which now either. I remember that I did much of the work on a v2 release, and Paolo did something very similar but we each did the work independently of the other. There is some reconciling to be done there too. My copy is in ftp://ftp.gnu.org/gnu/smalltal

Re: snprintfv

And how much of the L1 instruction cache? Intel's Pentium, Pentium Pro, Pentium III, Celeron 1.7 GHz each have only 8 KB of it. Make one call to snprintfv, and the cache is emptied. AMD64 has 64 KB of it; it's a bit better. Let's talk L2 cache. I doubt glibc has a smaller printf, and anyway I

Re: snprintfv for gnulib?

- The unlocked I/O module isn't actually what snprintfv wants. It needs flockfile and unlocked-io.h defines that to nothing. All it really wants is an autoconf check for unlocked IO. Yes, the same thing that gnulib does in getdelim: #if !HAVE_FLOCKFILE # undef flockfile # define flockfi

Re: snprintfv for gnulib?

How should I initially configure this? It has a couple of support files already (compile, ltmain.sh) but not in the build-aux directory where it wants to find them, and not all of the necessary files e.g. config.sub. If the right answer is just "use --add-missing", then should we delete the exis

Re: snprintfv for gnulib?

I don't think I copied you on an email -- there is a bug fix and a number of warning fixes in my version that did not make it into the smalltalk version. I think some, at least, are in the libsnprintfv sources. I think it will be worth checking. (Paolo - I'm at work -- could you forward him m

Re: bug in frexpl module

frexpl of 1.0L should return the exponent 1 and mantissa 0.5L. Glibc does this. The substitute code in frexpl.c, however, returns the exponent 0 and mantissa 1.0L, which IMO is wrong. OK to fix this? Ok for all. Don't even ask for approval of changes like the testsuite, since you're much mo

Re: new module 'printf-frexpl'

Bruno Haible wrote: Similarly to 'printf-frexp', here is the corresponding module for 'long double'. What's the difference from frexpl and why can't we obsolete that one? Paolo

Re: Reconciliation of libsnprintfv vs. autogen

In the autogen sources it appears to be named SNV_ASSERT_FCN. In the libsnprintfv repository, it's named SNV_ASSERT_FMT - just grep for it. Which one should it be? Can't have half and half. FCN seems more meaningful. Paolo

Re: unistdio

and (B) the printf I spent all weekend working on merging? So far, it's unrelated. snprintfv lets me define my own handler for %U or similar, but I don't see how to produce UTF-16 or UTF-32 strings with snprintfv, and how to take UTF-16 or UTF-32 strings as arguments without dirty casting. L

Re: Building universal binaries makes 'check' fail

+[[#if ! (defined __BIG_ENDIAN__ || defined __LITLE_ENDIAN__) typo

Re: snprintfv for gnulib?

The existing snprintfv supports both use as a libtool convenience library and installation as a separate standalone library. Since we're merging this into gnulib, can we drop the standalone library? I'm hoping to rely entirely on gnulib infrastructure (e.g. for portability issues that libsnprin

Re: snprintfv for gnulib?

The existing snprintfv supports both use as a libtool convenience library and installation as a separate standalone library. Since we're merging this into gnulib, can we drop the standalone library? Currently, the standalone library has the possibility to load additional external modules. I

Re: new module 'frexp'

Bruno Haible wrote: > NetBSD does not only have a broken isnanl() function. It also has a broken > frexp(): it does not treat denormalized numbers correctly. > > Here is a replacement module for frexp(). Paolo, I tried using your > algorithm from frexpl.c, but > - I cannot enable it since it is

Re: new module 'frexp'

Bruno Haible wrote: > Paolo Bonzini wrote: >> I think you can zap my algorithm from the new file > > OK, I thought you would debug the test failure and give permission to use it > under LGPL. Unfortunately I don't have time to do so in the next few weeks. Of course, thoug

Re: mathl and NaN

> So, your opinion about the following patch? Ok; at the time i wrote mathl, there was (as you know) no isnanl package. I think ==, !=, isordered, isunordered comparisons are the sole operations you can safely perform on a SNaN. Paolo

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

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

h the others. Paolo 2008-09-23 Paolo Bonzini <[EMAIL PROTECTED]> * tests/test-poll.c: Downgrade minimum needed Winsock version. --- ChangeLog |4 tests/test-poll.c |2 +- 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/tests/test-poll.c b/tests/test-p

[PATCH 2/3] add winsock wrappers

e (_close calls CloseHandle). It doesn't do harm though, because I return the result of closesocket and discard any failure of _close. Tested together with patch 3/3. Ok? Paolo 2008-09-23 Paolo Bonzini <[EMAIL PROTECTED]> * lib/sys_socket.in.h: Do not implement rpl_setsoc

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

the result This finally works under native Win32 (giving the same result as Cygwin) and under Wine (except for a crash in test_pipe, bug 15272 in Wine's bugzilla). I tested it also with -DINTERACTIVE. I will commit it together with patch 2/3. Paolo 2008-09-23 Paolo Bonzini <[EMAIL P

[PATCH] implement full-blown select(2) for winsock

less expect this code to lay unchanged for years, as is often the case with this kind of platform emulation hacks. Tested under Wine. I'd appreciate more testing before committing it. Thanks, Paolo 2008-09-23 Paolo Bonzini <[EMAIL PROTECTED]> * lib/sys_socket.in.h: Remo

Re: [PATCH 2/3] add winsock wrappers

> The rpl_close wrapper in winsock.c will collide with the one in fchdir.c. > We can work on it after you commit your patch. I'll leave this to you... > Also, I would like to have select() implemented right, as I need it in the > 'msgfilter' program. But that's also for afterwards. ... as a deal

Re: [PATCH 2/3] add winsock wrappers

Simon Josefsson wrote: > Paolo Bonzini <[EMAIL PROTECTED]> writes: > >> Tested together with patch 3/3. Ok? > > I haven't tested it, but will do now that it has been installed. > > However, just to confirm, the sys_socket module needs to remain >

Re: [PATCH] implement full-blown select(2) for winsock

> I don't think this code should be built just because someone wanted the > sys/socket.h header and added the sys_socket module. There are many > places you want the sys/socket.h header without calling select. Ok, I'll place it into sys_select instead. > Compare other header files and system >

[PATCH v2] implement full-blown select(2) for winsock

t; modules, since without it the provided sys/select.h file would be totally useless. The actual code is the same as the previous patch. Paolo 2008-09-23 Paolo Bonzini <[EMAIL PROTECTED]> * lib/sys_select.in.h: Install select wrapper. * lib/sys_socket.in.h: Use a new

Re: [PATCH] implement full-blown select(2) for winsock

>> The difference is that without these fixes, winsock is simply just too >> crippled for the casual Unix programmer. Providing sys/socket.h and >> sys/select.h without anything like these wrappers was just giving a >> false sense of portability. > > I think that is consistent with how gnulib wo

Re: [PATCH] implement full-blown select(2) for winsock

> the stdio module [...] > does not pull in the fopen module, even though the fopen module > makes fopen function work *the way anyone including stdio.h would > expect them work*. I disagree on the "anyone" part. I never missed the fopen module, but I'm sure everyone who wrote cross-platform soc

Re: [PATCH v2] implement full-blown select(2) for winsock

Simon Josefsson wrote: > Paolo Bonzini <[EMAIL PROTECTED]> writes: > >> This revised patch includes the select(2) wrapper in sys_select, >> not sys_socket. This makes sense given the very purpose of the >> wrapper -- which is to let the client use select for other d

Re: [PATCH] implement full-blown select(2) for winsock

> In this case, the tradition is that the gnulib module > name is named after the function and not the header file, though, so > possibly you could rename sys_select to select? Maybe it is not worth > the breakage though, you decide. Maybe later. I also think it should be renamed, but I'm not su

[PATCH] Enhanced select(2) test

TECTED]>, 2007. */ /* Enhanced by Paolo Bonzini, 2008. */ #include #include #include #include #include #include #include #include #include #include #include "sockets.h" enum { SEL_IN = 1, SEL_OUT = 2, SEL_EXC = 4 }; #if (defined _WIN32 || defined __WIN32__) &

Re: fopen bug on Solaris, HP-UX

> ! fd = open (filename, O_RDONLY); > ! if (fd < 0) > return NULL; > > ! if (fstat (fd, &statbuf) >= 0 && !S_ISDIR (statbuf.st_mode)) > ! { > ! errno = ENOTDIR; > ! return NULL; > ! } You're leaking fd here. Same for open(). Paolo

Re: [PATCH] Enhanced select(2) test

Paolo Bonzini wrote: > Here is the test I'm using to check the correctness of sys_select. Committed together with the other select stuff after testing on a real Windows machine. Paolo

Re: [PATCH]: Missing tests-base in gnulib-cache.m4

> - After generating the autotools build system, doing 'make check' will > result in the following error (only when cross compiling for Win32 > systems): "make check" does not work for Windows crosses because check-TESTS depends on $(TESTS), which includes "test-allocaopt". So make attempts to m

Re: [PATCH]: Missing tests-base in gnulib-cache.m4

Ralf Wildenhues wrote: > * Paolo Bonzini wrote on Thu, Sep 25, 2008 at 12:43:05PM CEST: >>> - After generating the autotools build system, doing 'make check' will >>> result in the following error (only when cross compiling for Win32 >>> systems): >>

Re: winsock wrapper tweaks

Bruno Haible wrote: > Hi Paolo, > > In gettext, when building on mingw, I compile gnulib in C mode but use some > of it in C++ mode. I got link errors because of rpl_select and rpl_close. > Adding the usual 'extern "C" { ... }' in the header file fixed it. OK? > > Also, I compile with -Wall, and

[PATCH] enhance the bootstrap script to support gnulib as a submodule

clone, not just a shallow one or a copy without the .git metadata. Tested on sed's repository. Ok? Paolo 2008-09-29 Paolo Bonzini <[EMAIL PROTECTED]> * build-aux/bootstrap: Use git's submodules if the project includes a registered submodule named gnulib. dif

[PATCH] Install git-merge-changelog in bootstrap

2008-09-29 Paolo Bonzini <[EMAIL PROTECTED]> * bootstrap: Install git-merge-changelog configuration entries if git is in use. --- build-aux/bootstrap.save2008-09-29 11:46:29.0 +0200 +++ build-aux/bootstrap 2008-09-29 11:44:39.0 +0200 @@ -218,6 +

Re: on OSF/1

ate > select function after all: someone might want to get the 'struct > timeval' structure out of sys/select.h without calling the select > function. I don't think so. It just means that the "self-containedness" test of sys/select.h fails by mistake. What about th

[PATCH] Update doc for socket functions

The attached patch updates the documentation on socket functions after the recent Winsock commits. Ok? Paolo 2008-08-24 Paolo Bonzini <[EMAIL PROTECTED]> * doc/posix-functions/accept.texi: Update mingw problems. * doc/posix-functions/bind.texi: Update mingw pr

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

> *** 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: on OSF/1

Bruno Haible wrote: > Hi Paolo, > >> What about this patch? Bruno, can you give it a try on OSF/1? > > The patch is obviously correct. You can apply it, together with this > enhancement of the unit test. I'll test it in the next few days. Done. Paolo

Re: [PATCH] enhance the bootstrap script to support gnulib as a submodule

> Is it still possible to save space by hardlinking gnulib's object > storage with that of other gnulib trees? It does so by default, apparently: ~/sed/gnulib/.git/objects/ff bonzinip$ ls -l total 12 -r--r--r-- 2 377 Sep 23 11:49 56cbaeb94df799287111d03f35a345e351704f -r--r--r-- 2 416 Sep 23 1

[PATCH] Support renaming bootstrap

This would break compatibility. Otherwise, ok? Paolo 2008-09-29 Paolo Bonzini <[EMAIL PROTECTED]> * build-aux/bootstrap: Support renaming the bootstrap script. diff --git a/build-aux/bootstrap b/build-aux/bootstrap index 74fa3eb..2866770 100755 --- a/build-aux/bootstrap

Re: [PATCH v2] implement full-blown select(2) for winsock

Bruno Haible wrote: > Hi Paolo, > > Thank you for providing this select() implementation! With it, I can now make > 'msgfilter' work on mingw. > > Here's a patch for a possible optimization: select() on a regular file > should return "ready" always, no? There's no need to even call > WaitForSingl

Re: [PATCH v2] implement full-blown select(2) for winsock

> How about adding an assertion like this? > > + if (!timeout && rc == 0) > + abort (); But wouldn't this trigger in your case, thus aborting select() and poll()? > But I am afraid to propose this as a fix, because this is busy-looping, and > the purpose of select() is to avoid busy-looping

Re: [PATCH v2] implement full-blown select(2) for winsock

> No, please. I don`t need sockets. For communication with a subprocess, all > I need is a pipe. Sockets would be an overkill for that. I agree, but it seems like pipe WaitForSingleObject is broken. You'd need a thread polling with PeekNamedPipe, or a busy-waiting loop in the main thread altoget

Re: [PATCH v2] implement full-blown select(2) for winsock

Bruno Haible wrote: > Paolo Bonzini wrote: >> I agree, but it seems like pipe WaitForSingleObject is broken. You'd >> need a thread polling with PeekNamedPipe, or a busy-waiting loop in the >> main thread altogether. > > Maybe we need to reset the pipe from &q

Re: Preliminary patch for flock (just for discussion)

Bruno Haible wrote: > Hi, > > Richard W.M. Jones wrote: >> here is a preliminary patch for flock support for Windows. > > Three comments. > > * About the function. Why flock() and not lockf()? > There are three APIs for locking: > - lockf in POSIX [1], > - fcntl in POSIX [2], > - f

[RFH] macro ordering problems in sed

Hi all, git sed gives this problem when running "sh autoboot": configure.ac:17: warning: AC_COMPILE_IFELSE was called before AC_GNU_SOURCE ../../lib/autoconf/specific.m4:331: AC_GNU_SOURCE is expanded from... configure.ac:17: the top level configure.ac:17: warning: AC_RUN_IFELSE was called before

Re: [RFH] macro ordering problems in sed

> Here's a patch that does the job, at the expense of > switching to AM_GNU_GETTEXT([external]). I switched coreutils > to that approach a long time ago and haven't looked back. > No one has complained, either. Great, thanks. Paolo

Re: tee logs no output if stdout is closed

> I cannot change 'close-stream', since you own that module. But for > 'fwriteerror', > which I use in GNU gettext - and where I don't want to have spurious, timing- > dependent error messages - I'm applying this: I tend to agree with you on EPIPE, but OTOH this is as bad as it can be. Can't we

Re: tee logs no output if stdout is closed

Jim, > Imagine a scenario in which the pipe reader is expected always to > be reading, and so the pipe writer can expect that any write failure with > errno==EPIPE indicates the reader has terminated unexpectedly. If the writer should terminate first, the reader can still detect the failure using

Re: tee logs no output if stdout is closed

Bruno Haible wrote: > Paolo Bonzini wrote: >> Is it possible to implement the "tee >> --ignore-sigpipe" as you did (delaying SIGPIPE until the last input >> closes, which I also think is the right thing to do) while having >> close-stream ignore EPIPE? > &g

Re: Preliminary patch for flock (just for discussion)

>> But lockf unlike flock does not support shared locks, which are very >> useful. I can take care of implementing it in terms of fcntl when >> Richard's patch goes in. > > Very good point. You can write flock() in terms of fcntl()? Yes, simply like this: struct flock fl; fl.l_start = 0;

Re: tee logs no output if stdout is closed

Jim Meyering wrote: > Paolo Bonzini <[EMAIL PROTECTED]> wrote: >> Jim, >> >>> Imagine a scenario in which the pipe reader is expected always to >>> be reading, and so the pipe writer can expect that any write failure with >>> errno==EPIPE indicates t

Re: installable gnulib library

> Yes, and actually, that bugs me quite a lot. While gnulib is still finding > its feet, that's still acceptable, but at some point (the core interfaces of) > gnulib really ought to settle down. And I've moaned on and off that it > really would be very nice (for the sake of being able to rebuild

Re: tee logs no output if stdout is closed

Jim Meyering wrote: > Imagine a scenario in which the pipe reader is expected always to > be reading, and so the pipe writer can expect that any write failure with > errno==EPIPE indicates the reader has terminated unexpectedly. >>> >>> The above was assuming that SIGPIPE is being igno

Re: tee logs no output if stdout is closed

Bruno Haible wrote: > Paolo Bonzini wrote: >>> http://lists.gnu.org/archive/html/bug-coreutils/2008-09/msg00024.html >> Doesn't the comment in patch 2 > > To make it clear: > - Patch 1 only - applies if close_stdout were modified to ignore EPIPE >

Re: [PATCH] flock implementation (version 2)

Thanks! > +static BOOL > +do_lock_shared (HANDLE h, int non_blocking) > +static BOOL > +do_lock_exclusive (HANDLE h, int non_blocking) There's quite some duplication here. However, with the other changes below it might become acceptable. > + case ERROR_LOCK_VIOLATION: > + /* EWOULDBL

[PATCH] make EAGAIN == EWOULDBLOCK on Windows

This patch tweaks the mapping of error codes in the errno module and in winsock.c, so that under mingw EWOULDBLOCK is not different from EAGAIN. It was inspired by the flock patch. Ok? Paolo 2008-10-03 Paolo Bonzini <[EMAIL PROTECTED]> * lib/strerror.c: Return an error stri

Re: tee logs no output if stdout is closed

> What else do you propose to cover these cases, if not a global variable? If only one behavior is needed across an entire package, a dummy module with gl_MODULE_INDICATOR would do. Better than having fwriteerror do one thing and close_stdout do another. Paolo

Re: [PATCH] make EAGAIN == EWOULDBLOCK on Windows

>> This patch tweaks the mapping of error codes in the errno module and in >> winsock.c, so that under mingw EWOULDBLOCK is not different from EAGAIN. > > Why should this be done? POSIX [1] does not require this. Portable > applications > have to check against both EAGAIN and EWOULDBLOCK. But i

Re: [PATCH] make EAGAIN == EWOULDBLOCK on Windows

> The drawback of this move is that > >errno = EWOULDBLOCK; >perror (""); > > now prints "Resource temporarily unavailable", where before it printed > "Operation would block". But that's like on Linux. That's the "feature" > you get by merging two error codes into a single one. Yes, tha

Re: [PATCH] implement full-blown select(2) for winsock

> Here is a proposal that should acknowledge both of your arguments: > Provide separate modules 'select' separate from 'sys_select', like we do > in the rest of gnulib, but if 'sys_select' is used without 'select', then > #define select select_used_without_requesting_gnulib_module_select > so th

Re: [PATCH] implement full-blown select(2) for winsock

Bruno Haible wrote: > Paolo Bonzini wrote: >>> Here is a proposal that should acknowledge both of your arguments: >>> Provide separate modules 'select' separate from 'sys_select', like we do >>> in the rest of gnulib, but if 'sys_sele

  1   2   3   4   5   6   7   >