From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965553AbbEMVMD (ORCPT ); Wed, 13 May 2015 17:12:03 -0400 Received: from senator.holtmann.net ([87.106.208.187]:57886 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964839AbbEMVL7 convert rfc822-to-8bit (ORCPT ); Wed, 13 May 2015 17:11:59 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: [PATCH] Bluetooth: Pre-initialize variables in read_local_oob_ext_data_complete() From: Marcel Holtmann In-Reply-To: Date: Wed, 13 May 2015 23:11:56 +0200 Cc: "Gustavo F. Padovan" , Johan Hedberg , BlueZ development , netdev , "linux-kernel@vger.kernel.org" Content-Transfer-Encoding: 8BIT Message-Id: <0F69C638-5050-4603-A3FE-12FD8E9B27DD@holtmann.org> References: <1429212265-26750-1-git-send-email-geert@linux-m68k.org> <8684664B-22C2-45E8-B547-48F173B3CA7A@holtmann.org> To: Geert Uytterhoeven X-Mailer: Apple Mail (2.2098) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Geert, >>>>> net/bluetooth/mgmt.c: In function ‘read_local_oob_ext_data_complete’: >>>>> net/bluetooth/mgmt.c:6474: warning: ‘r256’ may be used uninitialized in this function >>>>> net/bluetooth/mgmt.c:6474: warning: ‘h256’ may be used uninitialized in this function >>>>> net/bluetooth/mgmt.c:6474: warning: ‘r192’ may be used uninitialized in this function >>>>> net/bluetooth/mgmt.c:6474: warning: ‘h192’ may be used uninitialized in this function >>>>> >>>>> While these are false positives, the code can be shortened by >>>>> pre-initializing the hash table pointers and eir_len. This has the side >>>>> effect of killing the compiler warnings. >>>> >>>> can you be a bit specific on which compiler version is this. I fixed one occurrence that seemed valid. However in this case the compiler seems to be just plain stupid. On a gcc 4.9, I am not seeing these for example. >>> >>> gcc 4.1.2. As there were too many false positives, these warnings were >>> disabled in later versions (throwing away the children with the bad water). >>> >>> If you don't like my patch, just drop it. I only look at newly >>> introduced warnings >>> of this kind anyway. >> >> I really do not know what is the best solution here. This is a false positive. And I have been looking at this particular code for a warning that was valid, but we missed initially. But these warnings that you are fixing are clearly false positive. > > I only sent patches to fix false positives if I think the patches improve the > code. As this is a subjective matter, it's up to you as the maintainer to > decide. > >> If this only happens with an old compiler version, I would tend to leave the code as is. Then again, what is the general preferred approach here? > > As this is a false positive, it's clearly up to the maintainer to > decide if the patch > improves the code or not. and in this case, I have no idea if I want to bother or not. I really just don’t. Since nobody else complained, I might just leave it as is since it really is a false positive. Regards Marcel