Re: New function xpalloc in module xalloc

On 4/3/21 11:17 PM, Marc Nieper-Wißkirchen wrote: Does the comparison make any sense, by the way? Yes, although it's needed only on unusual (and these days perhaps theoretical?) platforms where SIZE_MAX < PTRDIFF_MAX. I hadn't noticed the issue, as the projects I contribute to (coreutils,

Re: replacement for 'join'?

On 4/5/21 6:01 PM, Bruno Haible wrote: Wonderful! Thank you. Both solutions work fine with the 'awk' on Alpine Linux (BusyBox v1.32.1). It looks like you're talking about a simple one-field-per-line join. If so, the following should also work and is simpler: grep -Fvf file2 file1 though it

Re: replacement for 'join'?

Hi Berny, > > join -v 1 FILE1 FILE2 > > Maybe awk? > > $ awk -v keyfile=file2 ' > BEGIN { while ((getline < keyfile) > 0) k[$1]=1 } > !k[$1] > ' file1 > or > > $ awk ' > keys { k[$1]=1; next } > !k[$1] > ' keys=1 file2 keys=0 file1 Wonderful! Thank

Re: replacement for 'join'?

On 4/5/21 1:06 AM, Bruno Haible wrote: > Alpine Linux does not have the 'join' program. > The GCS [1] don't list it among the essential utilities. FWIW: join(1) is required by POSIX [1]: [1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/join.html > So, what kind of replacement for

Re: Using relocatable-prog with relocatable libraries

On Mon, 5 Apr 2021 at 23:36, Reuben Thomas wrote: > > The comment about "all the copies of relocatable.c" in progreloc.c is > surely is clue, but I cannot see how more than one copy of relocatable.c is > ever compiled… > Finally found, in relocatable-maint.texi, "If you need more than one

Re: Using relocatable-prog with relocatable libraries

On Mon, 5 Apr 2021 at 22:55, Reuben Thomas wrote: > > Have I missed something? I was surprised that I hadn't come across this > problem before, but I found that I've used relocatable-lib-lgpl before, but > not relocatable-prog (because in fact I was working with an LGPLed > project). > The

Using relocatable-prog with relocatable libraries

I use relocatable-prog in a project which builds a binary that links against a library which itself is installed publicly. Therefore, I build gnulib with -DIN_LIBRARY. This causes gnulib to be built with a static copy of compute_curr_prefix, named local_compute_curr_prefix. Therefore, when

Re: static analyzers

Marc Nieper-Wißkirchen wrote: > Coverity seems to be a good tool. Yes, it has found a number of mistakes in Gnulib code (handle leaks, memory leaks, use-after-free bugs, invalid free()), partially in really complex code that a human cannot easily review. > I haven't yet tested GCC's new static

[PATCH 1/1] hamt: Fix coding errors.

From: Marc Nieper-Wißkirchen Reported by Bruno Haible in after a Coverity run. * lib/hamt.c (bucket_do_while, hamt_iterator): Add missing derefencing operator and silence a bogus warning on uninitialized variables. *

Re: [PATCH] hamt: New module.

Hi Bruno, Am Mo., 5. Apr. 2021 um 15:02 Uhr schrieb Bruno Haible : > Hi Marc, > > > * tests/test-hamt.c: New file. > > Can you please have a quick look whether these Coverity findings (from our > weekly Coverity run) are relevant? > Coverity seems to be a good tool. I haven't yet tested GCC's

Re: [PATCH] hamt: New module.

Hi Marc, > * tests/test-hamt.c: New file. Can you please have a quick look whether these Coverity findings (from our weekly Coverity run) are relevant? *** CID 1503613: Null pointer

Re: [PATCH] lib/pthread-cond.c: use tv.nsec instead of tv.usec

Fabrice Fontaine wrote: > Use tv.nsec instead of tv.usec to avoid the following build failure: > > lib/pthread-cond.c: In function 'pthread_cond_wait': > lib/pthread-cond.c:121:16: error: 'struct timespec' has no member named > 'tv_usec'; did you mean 'tv_sec'? > 121 | duration.tv_usec =

Re: Node to first or last element of a sequential list in module list/xlist

Hi Bruno, Am Mo., 5. Apr. 2021 um 04:45 Uhr schrieb Bruno Haible : > [Adding back bug-gnulib in CC.] > Thanks! > > Is there a fundamental reason why a list walking algorithm that both > > inserts and removes items is not possible with an arbitrary Gnulib list > > container? Obviously, the

[PATCH] lib/pthread-cond.c: use tv.nsec instead of tv.usec

Use tv.nsec instead of tv.usec to avoid the following build failure: lib/pthread-cond.c: In function 'pthread_cond_wait': lib/pthread-cond.c:121:16: error: 'struct timespec' has no member named 'tv_usec'; did you mean 'tv_sec'? 121 | duration.tv_usec = 0; |^~~