Re: vasnprintf.c vs GCC11's -Wanalyzer-null-argument (and glibc-2.31)

On Sat, Jan 2, 2021 at 7:22 PM Paul Eggert wrote: > On 1/2/21 5:49 PM, Bruno Haible wrote: > > The vast majority of -Wanalyzer* warnings that we have seen so far were > > false > > alarms [1]. > > I've had such bad luck with those warnings that I have not been much > motivated to file GCC bug rep

Re: vasnprintf.c vs GCC11's -Wanalyzer-null-argument (and glibc-2.31)

Paul Eggert wrote: > I'd rather not work around those bugs as we can just ask > people to use --disable-gcc-warnings if their GCC is old. Yes. Or to set CPPFLAGS="-fno-analyzer" with GCC >= 10. Bruno

Re: vasnprintf.c vs GCC11's -Wanalyzer-null-argument (and glibc-2.31)

On 1/2/21 5:49 PM, Bruno Haible wrote: The vast majority of -Wanalyzer* warnings that we have seen so far were false alarms [1]. I've had such bad luck with those warnings that I have not been much motivated to file GCC bug reports for them. I guess the warnings are helpful with low-quality c

Re: test-free: fails with -flto=auto

Hi Bruno, On 1/3/21 3:06 AM, Bruno Haible wrote: > What was the result of > 'checking whether free is known to preserve errno...' > in your build? "... no" > > If it was 'yes', you've got a problem with the configure test. > > If it was 'no', it seems that you are hitting this GCC bug: > h

Re: mention the 'vcs-to-changelog' module on planet.gnu.org?

On 03-Jan-2021 07:49, Bruno Haible wrote: You might have noticed that we are currently publishing a news item per week about Gnulib in https://savannah.gnu.org/news/?group=gnulib ; they get propagated to http://planet.gnu.org/ . Would you want to write a short text about the 'vcs-to-changelog

mention the 'vcs-to-changelog' module on planet.gnu.org?

Hi Siddhesh, You might have noticed that we are currently publishing a news item per week about Gnulib in https://savannah.gnu.org/news/?group=gnulib ; they get propagated to http://planet.gnu.org/ . Would you want to write a short text about the 'vcs-to-changelog' module, for publication on 2021

mention the 'bitset' module on planet.gnu.org?

Hi Akim, You might have noticed that we are currently publishing a news item per week about Gnulib in https://savannah.gnu.org/news/?group=gnulib ; they get propagated to http://planet.gnu.org/ . Would you want to write a short text about the 'bitset' module, for publication on 2021-01-06 or 2021

Re: test-free: fails with -flto=auto

Hi Berny, > Reproducer: > > $ ./gnulib-tool --create-testdir --dir=/tmp/gl-free --single-configure > free-posix \ >&& cd /tmp/gl-free \ >&& env CFLAGS='-O2 -g -flto=auto' LDFLAGS='-O2 -g -flto=auto' > ./configure \ >&& make \ >&& make check > > Test failure: >

Re: vasnprintf.c vs GCC11's -Wanalyzer-null-argument (and glibc-2.31)

When I wrote: > So, in the current state, looking at -fanalyzer / -Wanalyzer outputs is > still a waste of time. I meant this with respect to Gnulib source code, which is usually reviewed by 2 people, which has unit tests, and so on. It is well possible that -fanalyzer / -Wanalyzer is useful to f

Re: vasnprintf.c vs GCC11's -Wanalyzer-null-argument (and glibc-2.31)

Hi Jim, > I built latest gcc from git and then attempted to build things with it. > I noticed this new warning while trying to build diffutils, but > haven't had time to address: The vast majority of -Wanalyzer* warnings that we have seen so far were false alarms [1]. This one is a false alarm a

Re: GNU SASL 1.9.2 and valgrind

Simon Josefsson wrote in : > > On Ubuntu 16.04 x86_64, in 32-bit mode (CC="gcc -m32"), configure, > > make, > > and "make install" work fine, but "make -k check" fails several > > tests: > > Right. It would be nice if gnulib's v

vasnprintf.c vs GCC11's -Wanalyzer-null-argument (and glibc-2.31)

I built latest gcc from git and then attempted to build things with it. I noticed this new warning while trying to build diffutils, but haven't had time to address: Making all in lib make[1]: Entering directory '/home/j/w/co/diffutils/lib' make all-am make[2]: Entering directory '/home/j/w/co/diff

valgrind-tests: Really enable the valgrind options test

The "checking for valgrind options for tests..." tests in module valgrind-tests does not work: It says "yes" even when these options don't work. Due to a reference to undefined variable gl_valgrind_opts. 2021-01-02 Bruno Haible valgrind-tests: Really enable the valgrind options test.

test-free: fails with -flto=auto

Hi Bruno, wondering why my build failed with the new free-posix module pulled in on openSUSE's build system, I tracked it down to the LTO compiler option. Reproducer: $ ./gnulib-tool --create-testdir --dir=/tmp/gl-free --single-configure free-posix \ && cd /tmp/gl-free \ && env

Re: Issues with posix functions on modern macOS/Xcode

Hi Martin, > > On macOS 10.15.7 (Catalina) on x86_64, both with Xcode 11.7 and 12.2, the > > following tests fail: > > > > FAIL: test-fprintf-posix3.sh > > FAIL: test-futimens > > FAIL: test-renameat > > FAIL: test-renameatu > > FAIL: test-strsignal > > FAIL: test-utime > > FAIL: test-utimens >

Re: test-getgroups.c:stringop-overflow warning on newer GCC

On 1/2/21 1:51 PM, Bruno Haible wrote: > 2021-01-02 Bruno Haible > > getgroups test: Avoid warning with glibc >= 2.32 and gcc >= 10. Thanks, works. Have a nice day, Berny

utimensat: Fix test failures on macOS

On macOS 10.13, I'm seeing test failures: FAIL: test-fdutimensat == ./test-utimens.h:75: assertion 'func (BASE "file", ts) == -1' failed FAIL test-fdutimensat (exit status: 134) FAIL: test-utimensat ./test-utimens.h:75: assertion 'func (BASE "file", ts)

utimens: Fix test failures on macOS

On macOS 10.13, I'm seeing test failures: FAIL: test-futimens === ../../gltests/test-futimens.h:170: assertion 'ctime_compare (&st3, &st2) < 0' failed FAIL test-futimens (exit status: 134) FAIL: test-utimens == ../../gltests/test-utimens.h:149: assertion 'ctime_

renameatu: Fix test failures on macOS

On macOS 10.13, I'm seeing these test failures (for a long time already). FAIL: test-renameat === ../../gltests/test-rename.h:619: assertion 'func (BASE "link2/", BASE "link2") == -1' failed FAIL test-renameat (exit status: 134) FAIL: test-renameatu ../../g

Re: test-getgroups.c:stringop-overflow warning on newer GCC

Paul Eggert wrote: > I see the problem on Fedora 33 as well. It doesn't appear to be a GCC > bug. unistd.h's declaration expands to this: > > extern int getgroups (int __size, __gid_t __list[]) __attribute__ > ((__nothrow__, __leaf__)) __attribute__ ((__access__ (__write_only__, 2, > 1))); > >

new module 'timespec_get'

One of the glibc functions that was added in 2012 already is actually specified in ISO C 11: 'timespec_get'. This set of patches implements it, as a thin wrapper around the 'gettime' module. 2021-01-02 Bruno Haible timespec_get: Add tests. * tests/test-timespec_get.c: New file