On 08/20/2018 12:16 PM, Thomas Huth wrote:

Maybe really set it to zero (memset) before using the g_strlcpy? I am
not a fan of disabling warnings, but if you think this is
easier/cleaner, let's go for that.
I'm not a fan of strlcpy in general (by the time you've properly set it 
up to detect/report/avoid truncation errors, you've added more 
boilerplate code than you would have by just doing memcpy() yourself).
FWIW, that new warning from GCC is IMHO just annoying. I had the same
problem in the SLOF sources, too:

https://github.com/aik/SLOF/commit/d8a9354c2a35136

The code with strncpy was perfectly valid before, but to get rid of the
warning, I replaced it with a more cumbersome memcpy instead (and mad
sure that the memory is already cleared earlier in that function). Now
seeing that the problem with strncpy pops up here, too, I think it would
maybe be better to shut up the warning of GCC, since it's clearly GCC
who's wrong here.
gcc is not necessarily wrong, as it CAN catch real erroneous uses of 
strncpy().  It's just that 99% of the time, strncpy() is the WRONG 
function to use, and so the remaining few cases where it actually does 
what you want are so rare that you have to consult the manual anyways. 
If nothing else, the gcc warning is making people avoid strncpy() even 
where it is safe (which is not a bad thing, in my opinion, because the 
contract of strncpy() is so counter-intuitive).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Reply via email to