Re: build-aux/snippet files

2013-11-11 Thread Nikos Mavrogiannopoulos
On Mon, 2013-11-11 at 13:51 -0700, Eric Blake wrote: > On 11/11/2013 01:34 PM, Nikos Mavrogiannopoulos wrote: > > Hello, > > It seems that gnulib-tool installs files in build-aux like > > "snippet/c++defs.h" that are under GPLv3+, even if the --lgpg=2 flag > > I assume you mean --lgpl=2 > > > is

Re: build-aux/snippet files

2013-11-11 Thread Eric Blake
On 11/11/2013 01:34 PM, Nikos Mavrogiannopoulos wrote: > Hello, > It seems that gnulib-tool installs files in build-aux like > "snippet/c++defs.h" that are under GPLv3+, even if the --lgpg=2 flag I assume you mean --lgpl=2 > is specified. If these headers are GPLv3+ shouldn't they be skipped in

build-aux/snippet files

2013-11-11 Thread Nikos Mavrogiannopoulos
Hello, It seems that gnulib-tool installs files in build-aux like "snippet/c++defs.h" that are under GPLv3+, even if the --lgpg=2 flag is specified. If these headers are GPLv3+ shouldn't they be skipped in that case? regards, Nikos

Re: [PATCH] base64: provide a fast path for encoding well sized buffers

2013-11-11 Thread Pádraig Brady
On 11/11/2013 06:37 PM, Paul Eggert wrote: > Pádraig Brady wrote: >> + static const char b64c[64] = >> +"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"; > ... >> + static const char b64c[64] = >> "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"; > >

Re: [PATCH] base64: provide a fast path for encoding well sized buffers

2013-11-11 Thread Paul Eggert
Pádraig Brady wrote: > + static const char b64c[64] = > +"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"; ... > + static const char b64c[64] = > "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"; There only needs to be one copy of b64c. > + if ((inl

Re: [PATCH] base64: provide a fast path for encoding well sized buffers

2013-11-11 Thread Pádraig Brady
On 11/11/2013 04:07 PM, Pádraig Brady wrote: > --- a/lib/base64.c > +++ b/lib/base64.c > - while (inlen && outlen) > + /* Note the outlen constraint can be enforced at compile time, > + while the inlen can change at runtime at the end of input. > + But the common case when reading large

Re: GNU gettext 0.18.3.1 fails with undefined _Bool on Solaris

2013-11-11 Thread Paul Eggert
Dagobert Michelsen wrote: > I tried adding -D_STDC_C99 to CPPFLAGS and I get compile errors at a > different place: Sorry, I don't use C++ much, but presumably your way of doing it messes up C++ in some cases, whereas mine just sticks to C, which is where the problem lies. > Did you also try th

[PATCH] base64: provide a fast path for encoding well sized buffers

2013-11-11 Thread Pádraig Brady
Avoid conditionals in the central base64 encoding loop, which was seen to give a 60% throughput improvement with the base64 utility from coreutils: $ truncate -s100MiB file.in $ time base64-old -w0 < file.in >/dev/null real 0m0.302s $ time base64-new -w0 < file.in >/dev/null real 0m0.182s * lib

Re: tight-scope check confusion

2013-11-11 Thread Jim Meyering
On Thu, Nov 7, 2013 at 9:52 AM, Reuben Thomas wrote: > On 7 November 2013 14:55, Jim Meyering wrote: >> >> Can you investigate, e.g., instrumenting those rules to see what's >> happening (then I don't have to ask for instructions on how to >> reproduce :-), for example, by, inserting "| tee /tmp/

Re: GNU gettext 0.18.3.1 fails with undefined _Bool on Solaris

2013-11-11 Thread Dagobert Michelsen
Hi Paul, thanks for the quick answer! Am 11.11.2013 um 09:46 schrieb Paul Eggert : > I wouldn't worry about the ACL checks, as gettext doesn't rely on ACLs. The problem is if one test fails our package system will not install. As a workaround I can disable the testsuite as a whole but would pre