Hi Bruno,
> Le 29 nov. 2018 à 01:03, Bruno Haible a écrit :
>
>> So, for consistency with the others, I'd to rename either the
>> file, or the enum: would you prefer BITSET_EXPANDABLE, ebitset
>> and bitset/expandable.h, or BITSET_TABLE, tbitset and
>> bitset/table.h?
>
> I would prefer the ter
* lib/strerror_r.c (safe_copy): Use memmove, not memcpy,
since the source and destination might overlap in the call
‘safe_copy (buf, buflen, strerror_r (errnum, buf, buflen))’.
Simplify.
---
ChangeLog| 8
lib/strerror_r.c | 21 ++---
2 files changed, 14 insertions
Hi Akim,
> bitset: rename BITSET_VARRAY as BITSET_VECTOR
Looks good to me.
> I have a problem with bitset/expandable.[hc], which
> defines ebitset_*: it corresponds to BITSET_TABLE.
>
>BITSET_TABLE: Expandable table of pointers to arrays of bits
> (variable size, less
> Ok to install?
Yes, it looks good to me.
Bruno
Hi Akim,
> Bruno, is this what you had in mind?
Yes, exactly!
> I could use macros to reduce to boilerplate, but whether
> to factor completely with macros, or avoid macros as much
> as possible at the cost of possible redundancy depends on
> people: which one do you want?
I don't have preferen
On Wed, Nov 28, 2018 at 10:40:05AM -0600, Eric Blake wrote:
> > Or is this an independent fix?
>
> Hard to say. Note that:
>
> printf %s "\015"
> printf %s "\\015"
>
> both output five bytes (single backslash, three digits, and a newline) -
> that's because in "", \ followed by an unknown char
Bruno, is this what you had in mind?
I could use macros to reduce to boilerplate, but whether
to factor completely with macros, or avoid macros as much
as possible at the cost of possible redundancy depends on
people: which one do you want?
It did catch a bug, in expandable's implementation of 'n
Ok to install?
commit 6d20ab4850e6bf15013e5e5a83bca5c2f31d77f9
Author: Akim Demaille
Date: Wed Nov 28 21:55:00 2018 +0100
bitset: properly use false/true instead of 0/1 for Booleans
* lib/bitset/expandable.c, lib/bitset/vector.c: Use false/true, not
0/1, as Booleans.
diff --g
Ok to install?
I have a problem with bitset/expandable.[hc], which
defines ebitset_*: it corresponds to BITSET_TABLE.
BITSET_TABLE: Expandable table of pointers to arrays of bits
(variable size, less storage for large sparse sets).
Faster than BITSET_LIST f
On 11/28/18 10:00 AM, Bruno Haible wrote:
Hi Ben,
This patch silences some warnings from Shellcheck, mostly about using
POSIX $(..) command substitutions instead of old backtick
substitutions.
The script starts with '#!/bin/sh'. /bin/sh on IRIX does not support
$(...). But I think no GNU main
Hi Ben,
> This patch silences some warnings from Shellcheck, mostly about using
> POSIX $(..) command substitutions instead of old backtick
> substitutions.
The script starts with '#!/bin/sh'. /bin/sh on IRIX does not support
$(...). But I think no GNU maintainer is using IRIX on their developmen
These changes look good to me in general.
Always happy to see backticks removed and replaced with the new form.
* Ben Elliston [181128 09:55]:
> This patch silences some warnings from Shellcheck, mostly about using
> POSIX $(..) command substitutions instead of old backtick
> substitutions.
>
>
On Tue, Nov 27, 2018 at 07:47:12PM +0100, Bruno Haible wrote:
> Eric Blake wrote:
> > > In other words, can you guarantee that $(GREP) will never expand to empty?
> >
> > If we change gl_INIT() to AC_REQUIRE([AC_PROG_GREP]), then that should
> > be sufficient to ensure $(GREP) is set by the time
On Tue, Nov 27, 2018 at 07:40:24PM +0100, Bruno Haible wrote:
> Roman Bolshakov wrote:
> > if test -n "$$files"; then
> > \
> > if test -n "$$prohibit"; then \
> > - grep $$with_grep_options $(_ignore_case
On Tue, Nov 27, 2018 at 07:19:43PM +0100, Bruno Haible wrote:
> Hi,
>
> > The workaround is to split argument list into chunks that operating
> > system can process. "getconf ARG_MAX" is used to determine size of the
> > chunk.
>
> Two questions on this:
>
> 1) People say that 'getconf ARG_MAX'
15 matches
Mail list logo
