[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] sheepdog build warning
From: |
Michael S. Tsirkin |
Subject: |
[Qemu-devel] sheepdog build warning |
Date: |
Mon, 17 Dec 2018 23:03:11 -0500 |
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?
--
MST
- [Qemu-devel] sheepdog build warning,
Michael S. Tsirkin <=