From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Carpenter Date: Thu, 14 Apr 2016 20:05:00 +0000 Subject: Re: [patch] firmware: qemu_fw_cfg.c: potential unintialized variable Message-Id: <20160414200500.GI4247@mwanda> List-Id: References: <20160414093337.GD16549@mwanda> <20160414184005.GC7821@HEDWIG.INI.CMU.EDU> <20160414191253.GH4247@mwanda> <20160414193614.GE7821@HEDWIG.INI.CMU.EDU> In-Reply-To: <20160414193614.GE7821@HEDWIG.INI.CMU.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: "Gabriel L. Somlo" Cc: "Michael S. Tsirkin" , qemu-devel@nongnu.org, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org Ah... I see now. You're right. Thanks for the explanation. On my config those functions are no-ops so the variable isn't initialized. If they were enabled then *probably* it wouldn't generate a warning. Probably just silencing the warning is the way to go though... I bet GCC optimizes it away. Let me think about this some more... regards, dan carpenter From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751557AbcDNUFo (ORCPT ); Thu, 14 Apr 2016 16:05:44 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:42810 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751044AbcDNUFn (ORCPT ); Thu, 14 Apr 2016 16:05:43 -0400 Date: Thu, 14 Apr 2016 23:05:00 +0300 From: Dan Carpenter To: "Gabriel L. Somlo" Cc: "Michael S. Tsirkin" , qemu-devel@nongnu.org, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org Subject: Re: [patch] firmware: qemu_fw_cfg.c: potential unintialized variable Message-ID: <20160414200500.GI4247@mwanda> References: <20160414093337.GD16549@mwanda> <20160414184005.GC7821@HEDWIG.INI.CMU.EDU> <20160414191253.GH4247@mwanda> <20160414193614.GE7821@HEDWIG.INI.CMU.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160414193614.GE7821@HEDWIG.INI.CMU.EDU> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: userv0022.oracle.com [156.151.31.74] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ah... I see now. You're right. Thanks for the explanation. On my config those functions are no-ops so the variable isn't initialized. If they were enabled then *probably* it wouldn't generate a warning. Probably just silencing the warning is the way to go though... I bet GCC optimizes it away. Let me think about this some more... regards, dan carpenter From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39897) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqnWK-0006rU-Uk for qemu-devel@nongnu.org; Thu, 14 Apr 2016 16:05:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqnWG-000239-Vr for qemu-devel@nongnu.org; Thu, 14 Apr 2016 16:05:44 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:49419) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqnWG-00022y-OJ for qemu-devel@nongnu.org; Thu, 14 Apr 2016 16:05:40 -0400 Date: Thu, 14 Apr 2016 23:05:00 +0300 From: Dan Carpenter Message-ID: <20160414200500.GI4247@mwanda> References: <20160414093337.GD16549@mwanda> <20160414184005.GC7821@HEDWIG.INI.CMU.EDU> <20160414191253.GH4247@mwanda> <20160414193614.GE7821@HEDWIG.INI.CMU.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160414193614.GE7821@HEDWIG.INI.CMU.EDU> Subject: Re: [Qemu-devel] [patch] firmware: qemu_fw_cfg.c: potential unintialized variable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" Cc: "Michael S. Tsirkin" , qemu-devel@nongnu.org, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org Ah... I see now. You're right. Thanks for the explanation. On my config those functions are no-ops so the variable isn't initialized. If they were enabled then *probably* it wouldn't generate a warning. Probably just silencing the warning is the way to go though... I bet GCC optimizes it away. Let me think about this some more... regards, dan carpenter