On 2018-08-20 15:28, David Hildenbrand wrote: > On 20.08.2018 15:23, Paolo Bonzini wrote: >> On 18/08/2018 04:56, Philippe Mathieu-Daudé wrote: >>> Fedora 29 comes with GCC 8.1 which added the 'stringop-truncation' checks. >>> >>> Replace the strncpy() calls by g_strlcpy() to avoid the following warning: >>> >>> migration/global_state.c: In function 'global_state_store_running': >>> migration/global_state.c:45:5: error: 'strncpy' specified bound 100 >>> equals destination size [-Werror=stringop-truncation] >>> strncpy((char *)global_state.runstate, >>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> state, sizeof(global_state.runstate)); >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> Reported-by: Howard Spoelstra <hsp.c...@gmail.com> >>> Signed-off-by: Philippe Mathieu-Daudé <f4...@amsat.org> >>> --- >>> See http://lists.nongnu.org/archive/html/qemu-devel/2018-07/msg03723.html >>> >>> migration/global_state.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/migration/global_state.c b/migration/global_state.c >>> index 8e8ab5c51e..d5df502cd5 100644 >>> --- a/migration/global_state.c >>> +++ b/migration/global_state.c >>> @@ -42,7 +42,7 @@ int global_state_store(void) >>> void global_state_store_running(void) >>> { >>> const char *state = RunState_str(RUN_STATE_RUNNING); >>> - strncpy((char *)global_state.runstate, >>> + g_strlcpy((char *)global_state.runstate, >>> state, sizeof(global_state.runstate)); >>> } >>> >>> >> >> This is wrong because strlcpy doesn't zero the rest of > > Two RB-s and it is still wrong implies that string operations are still > the root of all evil. :) > >> global_state.runstate, so you could end up with something like >> "running\0ate\0\0..." in global_state.runstate However, the same mistake >> is already present in vl.c's runstate_store. >> >> Juan, David, what to do? strncpy is easy to misuse, but we do have >> cases where it's correct and it should tingle the reviewers' spidey >> senses... I wouldn't mind disabling the warning, and using strncpy in >> runstate_store, because in practice it's already reported by Coverity >> and it can be shut up there. > > 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.
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. Thomas
