From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id 5DC663858D28 for ; Sun, 23 Oct 2022 15:53:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5DC663858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org Received: by smtp.gentoo.org (Postfix, from userid 559) id F321A341186; Sun, 23 Oct 2022 15:53:38 +0000 (UTC) Date: Sun, 23 Oct 2022 20:24:13 +0545 From: Mike Frysinger To: Tsukasa OI Cc: Andrew Burgess , Nick Clifton , gdb-patches@sourceware.org Subject: Re: [PATCH 12/40] sim/frv: Initialize nesr variable Message-ID: Mail-Followup-To: Tsukasa OI , Andrew Burgess , Nick Clifton , gdb-patches@sourceware.org References: <021dbd238af5dfe74523ed229d2156a155a6bb9e.1666258361.git.research_trasio@irq.a4lg.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VjprszkJc1FQ6e09" Content-Disposition: inline In-Reply-To: <021dbd238af5dfe74523ed229d2156a155a6bb9e.1666258361.git.research_trasio@irq.a4lg.com> X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --VjprszkJc1FQ6e09 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 20 Oct 2022 09:32, Tsukasa OI wrote: > GCC generates a warning if a variable may be used uninitialized on some > cases ("-Wmaybe-uninitialized"). Despite that GCC will not cause a build > failure even when "--enable-werror" is specified, it would be nice to get > rid of it. >=20 > This commit initializes the variable nesr when declared. afaict, the code as written is not using nesr uninitialized (well, it does, but not in a way that changes behavior in the func, or is exposed out). so this looks fine because setting it to 0 initially in those cases also does not change behavior. i'm not familiar enough with FRV to say if pulling nesr from a diff place would be more safe to future code refactors. but since this port seems to largely be stable at this point, this is probably fine. -mike --VjprszkJc1FQ6e09 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmNVUhEACgkQQWM7n+g3 9YG4xw//R20LjJ48cS5fgG/wThtALmyTnLkF3m3tKTXlLOBbzcajjSJClKOISfAj Ig/6+lmFOQe+XmGrIEevItneRAG9vR8xJ2nzjnyXun3bMI2kWh4e5J1Ek0nq22An vLKHfqBhUhJVOY07Sv/87ZxzUGCUl7t0Yt0FFO8HZ98PrE5ERNJz+5pl/kYxUx3e TN3qtIdU16+PrhDLgrKIYAwsgRfqI/0RLX2ZcSu9ZL6b7XPhkepJvacwUVKJDslt /gCsp85cD+dXBjuj11H7cKNyd+I8yuLGK3tu+LHcURVUkaisuT5oS3/jSXfMKOlr QTgoKvrBMxfcKnpySUmZloknoxLE9gd/9n91LPSF9p0cMEOJbLlrrfJjLX1SaOA7 7oxLup3uaczaArj48YE+Zjhmurou081W0m/m4E+Ku7f61lf/tCHhQQKAPiFZ4pFA LWMzLPRnK8RbVlfGZyk67ymm9F+43hLxMCgiFAuqrpt/87g6nBVh0PtIKNgRJC/N dfffFhBfb+7dfljljO7ARNraFMbcXxOHYkNHrDxA5N1HbivhkrqRuAXmyS6ELFJA jByBQKKF4UmzmAGV2Iqg8SjakA79W9alMB5a0U/1fvfRvqdJBC7IBHq0cc7XyfEm 9qdQg/vNNEKj6MnTCdwOcCQmeHfk9VfVq5OxRbcfEKPgSEqVU9g= =dDH3 -----END PGP SIGNATURE----- --VjprszkJc1FQ6e09--