Re: strftime updates (was: Conflicting types for mblen on Solaris 2.6)

Jim Meyering wrote: > Bottom line: now that we have mbrlen and mbsinit modules, > there's no point in testing HAVE_MBRLEN. > > diff --git a/lib/strftime.c b/lib/strftime.c > index 897aab7..3ade8cf 100644 > --- a/lib/strftime.c > +++ b/lib/strftime.c > @@ -50,14 +50,7 @@ extern char *tzname[]; > #

Re: support for universal binaries on MacOS X (5/6)

Peter O'Gorman wrote: > > The configure test whether mktime works produces the result "yes" in 32-bit > > mode and "no" in 64-bit mode. ... > > This is surprising, what is the reason for the 64 bit failure? It is not surprising when you look at the function bigtime_test in m4/mktime.m4. Bruno

Re: bash, sed, SIGPIPE

Eric Blake wrote in : > > After 'trap - SIGPIPE', sed should get a fatal SIGPIPE signal in these > > conditions. > > Quoting > > > > > > "If action

Re: [PATCH 4/4] gnulib-tool: faster string handling for Posix shells.

Hello Ralf, 20% is a good speedup that you achieve here by use of shell built-ins instead of subprocesses and sed invocations. > * gnulib-tool (func_strip): New function. You only ever need to strip the prefix _or_ the suffix, never both simultaneously. Therefore it will be faster to define 2 fu

Re: [PATCH 0/4] faster gnulib-tool

Hello Ralf, Thank you for your speedups to gnulib-tool. At first I was, of course, excited about the 2x speedup. But when looking at the maintainability of the code that you propose, I'm not fine with all of it any more. My four objections are: 1) You observe that forking programs in a shell scr

Re: bash, sed, SIGPIPE

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 1/1/2009 5:09 PM: > After 'trap - SIGPIPE', sed should get a fatal SIGPIPE signal in these > conditions. > Quoting > > > "If action is '-'

Re: bash, sed, SIGPIPE

Hi Jim, > Also, even if I do reset the shell's sigpipe handler, > it doesn't change the fact that sed complains: > > $ (trap - SIGPIPE; seq 100|sed s/1/2/|cmp -s - /dev/null ) > sed: couldn't write 4 items to stdout: Broken pipe > [Exit 1] Now this looks like a bug either in 'sed

Re: Conflicting types for mblen on Solaris 2.6

"Tom G. Christensen" wrote: > The current daily snapshot is failing to build fprintftime: > depbase=`echo fprintftime.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ > gcc -std=gnu99 -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" > -DNO_XMALLOC -DEXEEXT=\"\" -I. -I.. -I../intl -I/usr/tgcware/includ

Re: sed, SIGPIPE, cmp -s [Re: [PATCH 3/4] gnulib-tool: abort loops early where possible.

Bruno Haible wrote: >>./bootstrap: Copying ._bootmp/gnulib-tests/Makefile.am to >> gnulib-tests/gnulib.mk... >> -sed: couldn't write 60 items to stdout: Broken pipe >> +sed: couldn't write 56 items to stdout: Broken pipe >> >> I see that it's technically harmless and comes from here: >> >

gnulib-tool: fix security bugs

This fixes a couple of security bugs. A user of gnulib-tool could cause damage to the fellow developers of his project by storing in gnulib-cache.m4 or gnulib-comp.m4 text like: gl_VC_FILES(`rm -rf /tmp/*`) AC_DEFUN([gl_FILE_LIST], [ foo bar `rm -rf /tmp/*` ]) 2009-01-01 Bruno Haible

Conflicting types for mblen on Solaris 2.6

The current daily snapshot is failing to build fprintftime: depbase=`echo fprintftime.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ gcc -std=gnu99 -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -DNO_XMALLOC -DEXEEXT=\"\" -I. -I.. -I../intl -I/usr/tgcware/include -D_REENTRANT -g -O2 -MT fprintfti

Re: sed, SIGPIPE, cmp -s [Re: [PATCH 3/4] gnulib-tool: abort loops early where possible.

Hi Jim, >./bootstrap: Copying ._bootmp/gnulib-tests/Makefile.am to > gnulib-tests/gnulib.mk... > -sed: couldn't write 60 items to stdout: Broken pipe > +sed: couldn't write 56 items to stdout: Broken pipe > > I see that it's technically harmless and comes from here: > > sed "$re

Re: [PATCH 3/4] gnulib-tool: abort loops early where possible.

Hello Ralf, > * gnulib-tool (func_modules_add_dummy, func_emit_lib_Makefile_am) > (func_emit_tests_Makefile_am, func_import): Abort loops early if > we already know the answer. Thanks Ralf. According to your timings, this patch provides a noticeable speedup and the code remains pretty. I've appli