[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH RFC] bunzip: work around gcc13 warning
- To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Fri, 3 Mar 2023 08:29:43 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WKT4JdsglRZPTHEzV39FFFEjDFV50TGZ2NHTLgwHKxc=; b=USHIFKiSaxRhPUuELzZ9cPg3/TGrx4cL74Au35bXkQznwaISc+m65dcFop3WhecI8LCD8fUjeotCQwTSY8eGmCsvRtVY4xCuQ78hhZkHZaPn7GdMbEqu5wyOo5zRxQrHtKv/++bfPzdae6fGwP2tY4soUp51x9ll5YOE8yQ4zb5lto1L1P9Zf553mxWTjSOSWm12hO6NwXL+pdTlA0kaMlK1/MbMGV7zlmh9bFgYveEmNDCdgARyqRKUacwc9KBS/TPjyOxVCBGIP/1nAQ9+F1oLXxVcHUGie7zZ+FgEX/sEDJ0yuwL/uHB1aNxAvvNT0ccWkzNeMa/NcuvxeMZZ0Q==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BPAWn+oFHPNXIsXfY9oMdCMl59IoWF0UC4p9RJ2NZ8ig+4UFsmTfTgFYdlJ+170GyzmFXAF/CO6++LQdiDLv8Sy8SWxTSxX6Dkpa1Q+XQ7HN03GKHC0vsqJI3YXjTcEXLKTP+LoAmAjH00LHVr43fqt6Z+x6B86YOYXOmsSMyOavPJ8yy81vFLLrL4x4eYSVvCHN/f4vU7VVFtsfuV12vXrwq9bMTQp5/n9Skj7rOMaZuf0/1Ug9eFcmNgxV4niOrQNASHlgZ6d64nuAfOkaXYxdsIEMqkIwC/JwNrFUC0gc2Mo6VPuqCOTp+xTRRjcp+LAJIfblAEsBoiLvIlc5eQ==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
- Delivery-date: Fri, 03 Mar 2023 07:29:55 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
While provable that length[0] is always initialized (because symCount
cannot be zero), upcoming gcc13 fails to recognize this and warns about
the unconditional use of the value immediately following the loop.
See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106511.
Reported-by: Martin Liška <martin.liska@xxxxxxxx>
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
---
RFC: We've cloned this code from Linux and the code is unchanged there.
Therefore the same issue should exist there, and we may better get
whatever workaround is going to be applied there. But I'm unaware
of the issue, so far, having been observed in and reported against
Linux. This may be because they disable the maybe-uninitialized
warning by default, and they re-enable it only when building with
W=2.
--- a/xen/common/bunzip2.c
+++ b/xen/common/bunzip2.c
@@ -233,7 +233,7 @@ static int __init get_next_block(struct
becomes negative, so an unsigned inequality catches
it.) */
t = get_bits(bd, 5)-1;
- for (i = 0; i < symCount; i++) {
+ for (length[0] = i = 0; i < symCount; i++) {
for (;;) {
if (((unsigned)t) > (MAX_HUFCODE_BITS-1))
return RETVAL_DATA_ERROR;
|
