Re: vasnprintf.c: "out_of_memory", -Wanalyzer-free-of-non-heap, -Wanalyzer-malloc-leak

On 4/30/22 17:24, Bruno Haible wrote: These dependencies save an 'errno = ENOMEM;' assignment in one or two places, but can cause integration problems; I am especially thinking at the use in GNU libintl and libasprintf. Ah, I didn't know about the integration problems. I was worried about the

Re: vasnprintf.c: "out_of_memory", -Wanalyzer-free-of-non-heap, -Wanalyzer-malloc-leak

Hi Paul, > I did a similar check before seeing your email It would be worth to eliminate the false positive reports by GCC. If only we could state the invariants in a form that GCC understands. We could use assume (result==resultbuf) for one part. But how to tell GCC that 'result' is heap-allo

Re: [platform-testers] Test failures for grep-3.7.62-9a668

On Sat, Apr 30, 2022 at 1:14 PM Bruno Haible wrote: > Nelson H. F. Beebe wrote: > > I did builds of grep-3.7.62-9a668 on 29 systems today ... > > > > On Solaris 11.4 x86_64: > > > > ../build-aux/test-driver: line 112: 14630: Memory fault > > ../build-aux/test-driver: line 112: 15129: M

Re: vasnprintf.c: "out_of_memory", -Wanalyzer-free-of-non-heap, -Wanalyzer-malloc-leak

On 4/30/22 14:11, Bruno Haible wrote: This is a false positive as well: Thanks for checking that. I did a similar check before seeing your email, and found some opportunities for simplifying the code so that these checks could be easier in the future. (With luck it'd also help avoid false po

Re: vasnprintf.c: "out_of_memory", -Wanalyzer-free-of-non-heap, -Wanalyzer-malloc-leak

Bjarni Ingi Gislason wrote: > > In function 'vasnprintf': > ../lib/vasnprintf.c:5849:7: warning: 'free' of 'result_334' which points > to memory not on the heap [CWE-590] [-Wanalyzer-free-of-non-heap] > 5849 | free (result); > ... This is a false positive. By code inspection, one can see

Re: vasnprintf.c: "out_of_memory", -Wanalyzer-free-of-non-heap, -Wanalyzer-malloc-leak

On 4/30/22 07:13, Bjarni Ingi Gislason wrote: With latest gnulib version: I'm not seeing this problem with the current (84863a1c4dc8cca8fb0f6f670f67779cdd2d543b) gnulib version on Fedora 35 x86-64, which has GCC 11.3.1 20220421 (Red Hat 11.3.1-2). Here's how I tried to reproduce the issu

Re: [platform-testers] Test failures for grep-3.7.62-9a668

Nelson H. F. Beebe wrote: > I did builds of grep-3.7.62-9a668 on 29 systems today ... > > On Solaris 11.4 x86_64: > > ../build-aux/test-driver: line 112: 14630: Memory fault > ../build-aux/test-driver: line 112: 15129: Memory fault > > Those were for test-iconv and test-striconv. Thi

vasnprintf.c: "out_of_memory", -Wanalyzer-free-of-non-heap, -Wanalyzer-malloc-leak

With latest gnulib version: commit d6a07b4dc21b3118727743142c678858df442853 (origin/master, origin/HEAD) Author: Simon Marchi Date: Fri Apr 29 01:47:55 2022 +0200 While compiling "groff" (for exampe while creating "grodvi") with gcc-11.3 options "-fanalyzer -Wanalyzer-mismatching-dealloca

Re: string.h on rhES 7

Tom Tromey wrote: > Hi. gdb recently updated gnulib to > > GNULIB_COMMIT_SHA1="0cda5beb7962f6567f0c4e377df870fa05c6d681" > > This caused a build failure here at AdaCore, where we are using a > relatively recent GCC (11.2) on an rhES 7 host: > > CC libgnu_a-openat-proc.o > In file inclu

Re: setlocale with NULL locale (to read current locale) segfaults on MSYS

Reuben Thomas wrote: > on MSYS it goes wrong > ... > setlocale_null_with_lock (category=category@entry=0, buf=buf@entry=0xbd80 > "", bufsize=bufsize@entry=3221) at setlocale_null.c:228 > 228 if (pthread_in_use()) > (gdb) > 230 pthread_mutex_t *lock = gl_get_setlocale_null_lock (