GCC 8 added a -Wstringop-truncation warning:

  The -Wstringop-truncation warning added in GCC 8.0 via r254630 for
  bug 81117 is specifically intended to highlight likely unintended
  uses of the strncpy function that truncate the terminating NUL
  character from the source string.

This new warning leads to compilation failures:

    CC      block/sheepdog.o
  qemu/block/sheepdog.c: In function 'find_vdi_name':
  qemu/block/sheepdog.c:1239:5: error: 'strncpy' specified bound 256 equals 
destination size [-Werror=stringop-truncation]
       strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN);
       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  make: *** [qemu/rules.mak:69: block/sheepdog.o] Error 1

As described previous to the strncpy() calls, the use of strncpy() is
correct here:

    /* This pair of strncpy calls ensures that the buffer is zero-filled,
     * which is desirable since we'll soon be sending those bytes, and
     * don't want the send_req to read uninitialized data.
     */
    strncpy(buf, filename, SD_MAX_VDI_LEN);
    strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN);

We could add a #pragma GCC diagnostic ignored "-Wstringop-truncation"
around, disable the warning globally using -Wno-stringop-truncation,
but since QEMU provides the strpadcpy() which does the same purpose,
simply use it to avoid the annoying warning.

Reported-by: Howard Spoelstra <hsp.c...@gmail.com>
Buglink: https://bugs.launchpad.net/qemu/+bug/1803872
Signed-off-by: Philippe Mathieu-Daudé <phi...@redhat.com>
---
 block/sheepdog.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/block/sheepdog.c b/block/sheepdog.c
index 0125df9d49..72e1aef6ea 100644
--- a/block/sheepdog.c
+++ b/block/sheepdog.c
@@ -1231,12 +1231,12 @@ static int find_vdi_name(BDRVSheepdogState *s, const 
char *filename,
         return fd;
     }
 
-    /* This pair of strncpy calls ensures that the buffer is zero-filled,
+    /* This pair of strpadcpy calls ensures that the buffer is zero-filled,
      * which is desirable since we'll soon be sending those bytes, and
      * don't want the send_req to read uninitialized data.
      */
-    strncpy(buf, filename, SD_MAX_VDI_LEN);
-    strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN);
+    strpadcpy(buf, SD_MAX_VDI_LEN, filename, '\0');
+    strpadcpy(buf + SD_MAX_VDI_LEN, SD_MAX_VDI_TAG_LEN, tag, '\0');
 
     memset(&hdr, 0, sizeof(hdr));
     if (lock) {
-- 
2.17.2


Reply via email to