Re: Lua and signal handlers

2012-01-31 Thread Bruno Haible
Reuben Thomas wrote: > The Lua bindings install a single signal handler that triggers a > callback at Lua's equivalent of a breakpoint. Obviously this is not > useful for everything, but it suffices, for example, to write handlers > for SIGTSTP and SIGWINCH (as Zile uses). And you can guarantee th

Re: SIGPOLL on Darwin

2012-01-31 Thread Reuben Thomas
On 31 January 2012 21:18, Bruno Haible wrote: > Reuben Thomas wrote: >> (SIGPOLL is mandated by POSIX). > > This is not true. Look at > > In the table, SIGPOLL is marked with OB and XSR. >  - [OB] means obsolescent. >  - [XSR

status on native Windows

2012-01-31 Thread Bruno Haible
Here's the current status of the POSIX emulation modules of gnulib on native Windows (*-*-mingw platforms), excluding known not working modules (mgetgroups, getugroups, idcache, userspec, openpty, login_tty, forkpty, pt_chown, grantpt, pty, savewd, mkancesdirs, mkdir-p, euidaccess, faccessat). Tes

Re: SIGPOLL on Darwin

2012-01-31 Thread Bruno Haible
Reuben Thomas wrote: > (SIGPOLL is mandated by POSIX). This is not true. Look at In the table, SIGPOLL is marked with OB and XSR. - [OB] means obsolescent. - [XSR] means XSI STREAMS. This is an optional part of POSIX that

Re: SIGPOLL on Darwin

2012-01-31 Thread Reuben Thomas
On 31 January 2012 15:51, Paul Eggert wrote: > On 01/31/2012 07:19 AM, Reuben Thomas wrote: >> SIGPOLL seems to be unimplemented on Darwin > > I don't offhand see an easy way to implement it in Gnulib, > so perhaps it's better that Gnulib doesn't define it. > (Sorry, I don't know the context.) I

Re: SIGPOLL on Darwin

2012-01-31 Thread bastien ROUCARIES
Le Tuesday 31 January 2012 16:19:54, Reuben Thomas a écrit : > gnulib's extensions module turns on _DARWIN_C_SOURCE on Darwin. > Unfortunately, this means that SIGPOLL is not defined, and hence stops > POSIX-compliant code from building (SIGPOLL is mandated by POSIX). As > extensions is required by

Re: SIGPOLL on Darwin

2012-01-31 Thread Paul Eggert
On 01/31/2012 07:19 AM, Reuben Thomas wrote: > SIGPOLL seems to be unimplemented on Darwin I don't offhand see an easy way to implement it in Gnulib, so perhaps it's better that Gnulib doesn't define it. (Sorry, I don't know the context.) > gnulib does not define _POSIX_C_SOURCE on Darwin, which

SIGPOLL on Darwin

2012-01-31 Thread Reuben Thomas
gnulib's extensions module turns on _DARWIN_C_SOURCE on Darwin. Unfortunately, this means that SIGPOLL is not defined, and hence stops POSIX-compliant code from building (SIGPOLL is mandated by POSIX). As extensions is required by some quite basic modules (the project I have in mind uses only manyw

popen on native Windows

2012-01-31 Thread Bruno Haible
On native Windows, the popen() or _popen() function terminates the current process with exit code 127 if getenv("COMSPEC") returns NULL. In one of my mingw environments, this triggered a failure of the autoconf test in m4/popen.m4, so that HAVE_POPEN and REPLACE_POPEN were set to 1, leading to thi

Re: base64 decoding more tolerant to chars

2012-01-31 Thread Bruno Haible
Jim Meyering wrote: > > Could also be done, but since the code to remove newlines was there, I > > thought it is simpler to augment it to remove common garbage. > > I am reluctant to make this low-level decoding function ignore anything > else. I agree. If you remove the garbage unconditionally,

Re: base64 decoding more tolerant to chars

2012-01-31 Thread Jim Meyering
Nikos Mavrogiannopoulos wrote: > On 01/30/2012 10:29 PM, Jim Meyering wrote: > >> Hi Nikos, >> Have you considered pre-filtering the data you pass to the base64-decoding >> function? We considered what you're proposing when adding the >> --ignore-garbage option to the command-line base64 program: