qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: qemu-devel@nongnu.org
Cc: Liu Yuan <namei.unix@gmail.com>, Jeff Cody <jcody@redhat.com>,
	qemu-block@nongnu.org, meyering@redhat.com,
	Kevin Wolf <kwolf@redhat.com>,
	MORITA Kazutaka <morita.kazutaka@lab.ntt.co.jp>,
	peter.maydell@linaro.org
Subject: Re: [Qemu-devel] sheepdog build warning
Date: Mon, 17 Dec 2018 23:16:05 -0500	[thread overview]
Message-ID: <20181217231145-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20181217224807-mutt-send-email-mst@kernel.org>

On Mon, Dec 17, 2018 at 11:03:11PM -0500, Michael S. Tsirkin wrote:
> mingw32 build on fedora fails with this warning:
> 
> /scm/qemu/block/sheepdog.c: In function 'find_vdi_name':
> /scm/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);
>      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
> make: *** [/scm/qemu/rules.mak:69: block/sheepdog.o] Error 1
> make: *** Waiting for unfinished jobs....
> 
> 
> Reading the code one sees it's working as intended:
> 
> 
> static int find_vdi_name(BDRVSheepdogState *s, const char *filename,
>                          uint32_t snapid, const char *tag, uint32_t *vid,
>                          bool lock, Error **errp)
> {
>     int ret, fd;
>     SheepdogVdiReq hdr;
>     SheepdogVdiRsp *rsp = (SheepdogVdiRsp *)&hdr;
>     unsigned int wlen, rlen = 0;
>     char buf[SD_MAX_VDI_LEN + SD_MAX_VDI_TAG_LEN];
> 
>     fd = connect_to_sdog(s, errp);
>     if (fd < 0) {
>         return fd;
>     }
> 
>     /* 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);
> 
> 
> .....
> 
> }
> 
> 
> 
> so this seems to be the case of GCC developers deciding that
> strncpy is simply a bad API and a correct use of it should be
> warned against.
> 
> I propose either
> 
> 1. simply adding
> 
> #pragma GCC diagnostic ignored "-Wstringop-truncation"
> 
> in osdep.
> 
> 2. adding an inline wrapper with said pragma in there.
> 
> 3. -Wno-stringop-truncation is the makefile
> 
> Thoughts?
> 
> -- 


So here's approach 2. However I note that a newer gcc 8.2.1
does not give this warning. Maybe detect at configure time
and suppress (option 3)?



diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
index 3bf48bcdec..64d8258529 100644
--- a/include/qemu/osdep.h
+++ b/include/qemu/osdep.h
@@ -134,6 +134,22 @@ extern int daemon(int, int);
 #define assert(x)  g_assert(x)
 #endif
 
+/*
+ * GCC 8.0 declared war on strncpy. Admittedly it's a tricky interface
+ * with unintuitive semantics, but we use it widely.
+ */
+#if defined(__GNUC__) && __GNUC__ >= 8
+static inline void qemu_strncpy(char *to, const char *from, int n)
+{
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wstringop-truncation"
+    strncpy(to, from, n);
+#pragma GCC diagnostic pop
+}
+
+#define strncpy qemu_strncpy
+#endif
+
 /*
  * According to waitpid man page:
  * WCOREDUMP

  reply	other threads:[~2018-12-18  4:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-18  4:03 [Qemu-devel] sheepdog build warning Michael S. Tsirkin
2018-12-18  4:16 ` Michael S. Tsirkin [this message]
2018-12-18 10:14   ` Philippe Mathieu-Daudé
2018-12-18 10:35   ` Daniel P. Berrangé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181217231145-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=jcody@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=meyering@redhat.com \
    --cc=morita.kazutaka@lab.ntt.co.jp \
    --cc=namei.unix@gmail.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).