From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53360) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvsbK-0006TF-4t for qemu-devel@nongnu.org; Mon, 30 Jul 2012 12:13:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SvsbI-0004yT-Uj for qemu-devel@nongnu.org; Mon, 30 Jul 2012 12:13:46 -0400 Received: from mail-gh0-f173.google.com ([209.85.160.173]:40574) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvsbI-0004yG-Qv for qemu-devel@nongnu.org; Mon, 30 Jul 2012 12:13:44 -0400 Received: by ghrr14 with SMTP id r14so4856543ghr.4 for ; Mon, 30 Jul 2012 09:13:44 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <5ddedba0015c15117770b3d1860f7dd6d8d08a0c.1343664167.git.blauwirbel@gmail.com> References: <5ddedba0015c15117770b3d1860f7dd6d8d08a0c.1343664167.git.blauwirbel@gmail.com> Date: Mon, 30 Jul 2012 17:13:43 +0100 Message-ID: From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH 2/5] sparc: fix expression with uninitialized initial value List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: blauwirbel@gmail.com Cc: qemu-devel@nongnu.org On 30 July 2012 17:04, wrote: > From: Blue Swirl > > err was uninitalized, it's not OK to use |=. Spotted by Clang "uninitialized" (feel free to just fix typo on commit). > compiler. > > Fix by replacing |= by =. > > Signed-off-by: Blue Swirl > --- > linux-user/signal.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/linux-user/signal.c b/linux-user/signal.c > index 97f30d9..3d6b5df 100644 > --- a/linux-user/signal.c > +++ b/linux-user/signal.c > @@ -2061,7 +2061,7 @@ restore_fpu_state(CPUSPARCState *env, qemu_siginfo_fpu_t *fpu) > err = __copy_from_user(&env->fpr[0], &fpu->si_float_regs[0], > (sizeof(unsigned long) * 32)); > #endif > - err |= __get_user(env->fsr, &fpu->si_fsr); > + err = __get_user(env->fsr, &fpu->si_fsr); > #if 0 > err |= __get_user(current->thread.fpqdepth, &fpu->si_fpqdepth); > if (current->thread.fpqdepth != 0) This will need changing again if we ever fix the #if 0-d out code in this function, but I guess that will be obvious to whoever does that. Incidentally, __get_user() can never fail [we catch unreadable memory earlier when wo do the lock_user_struct] so you could also just not do anything with its return value. Some of the other targets rely on this in their signal save/restore code. I think the use of the return value is mostly in code that was copy-and-pasted from the Linux kernel (which does use a __get_user() that can fail). Reviewed-by: Peter Maydell -- PMM