bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libvirt] [PATCH] maint: update to latest gnulib


From: Andrea Bolognani
Subject: Re: [libvirt] [PATCH] maint: update to latest gnulib
Date: Tue, 17 Jul 2018 10:14:18 +0200

On Sat, 2018-07-14 at 09:20 +0200, Michal Privoznik wrote:
> The changelog is quite long because we haven't updated gnulib in
> a while. Anyway, among the new changes you'll find GCC 8 support,
> faster build time, mingw fixes and many others.

Ironically, this makes building on MinGW *worse* :)

Looking at the CentOS CI, you can see that before[1] updating
gnulib the build failed with

  In function 'virStrncpy',
      inlined from 'virStrcpy' at ../../src/util/virstring.c:811:12:
  ../../src/util/virstring.c:789:11: error: 'strncpy' output truncated before 
terminating nul copying as many bytes from a string as its length 
[-Werror=stringop-truncation]
       ret = strncpy(dest, src, n);
             ^~~~~~~~~~~~~~~~~~~~~
  ../../src/util/virstring.c: In function 'virStrcpy':
  ../../src/util/virstring.c:811:12: note: length computed here
       return virStrncpy(dest, src, strlen(src), destbytes);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

and after[2] it fails with

  ../../src/util/virrandom.c: In function 'virRandomInt':
  ../../src/util/virrandom.c:102:30: error: implicit declaration of function 
'ffs' [-Werror=implicit-function-declaration]
           return virRandomBits(ffs(max) - 1);
                                ^~~

If you tweak the code to get rid of the ffs() call, you'll see
that the strncpy() error is not resolved - it's merely being swept
under the rug by the new one.

It looks like gnulib commit 2afc250c6fae changed the ffs()
detection code, and now when compiling with MinGW I get HAVE_FFS=1
instead of HAVE_FFS=0 and the failure above. Curiously, HAVE_FFS
only shows up in Makefiles after the commit, whereas before I had
the classic '#undef HAVE_FFS' in config.h as well.

CC'ing bug-gnulib and the patch author so they can take a look.

As for the strncpy() issue, it looks like the latest MinGW in
Rawhide introduced more strict diagnostics that are being mistakenly
triggered in this scenario. I'm looking into it.


[1] https://ci.centos.org/view/libvirt/job/libvirt-master-build-mingw32/238/
[2] https://ci.centos.org/view/libvirt/job/libvirt-master-build-mingw32/239/
-- 
Andrea Bolognani / Red Hat / Virtualization



reply via email to

[Prev in Thread] Current Thread [Next in Thread]