From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932228AbbDQUiy (ORCPT ); Fri, 17 Apr 2015 16:38:54 -0400 Received: from senator.holtmann.net ([87.106.208.187]:36377 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751882AbbDQUiw convert rfc822-to-8bit (ORCPT ); Fri, 17 Apr 2015 16:38:52 -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: Fri, 17 Apr 2015 13:38:47 -0700 Cc: "Gustavo F. Padovan" , Johan Hedberg , BlueZ development , netdev , "linux-kernel@vger.kernel.org" Content-Transfer-Encoding: 8BIT Message-Id: <8684664B-22C2-45E8-B547-48F173B3CA7A@holtmann.org> References: <1429212265-26750-1-git-send-email-geert@linux-m68k.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. 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? Regards Marcel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcel Holtmann Subject: Re: [PATCH] Bluetooth: Pre-initialize variables in read_local_oob_ext_data_complete() Date: Fri, 17 Apr 2015 13:38:47 -0700 Message-ID: <8684664B-22C2-45E8-B547-48F173B3CA7A@holtmann.org> References: <1429212265-26750-1-git-send-email-geert@linux-m68k.org> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "Gustavo F. Padovan" , Johan Hedberg , BlueZ development , netdev , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" To: Geert Uytterhoeven Return-path: In-Reply-To: Sender: linux-bluetooth-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: netdev.vger.kernel.org Hi Geert, >>> net/bluetooth/mgmt.c: In function =E2=80=98read_local_oob_ext_data_= complete=E2=80=99: >>> net/bluetooth/mgmt.c:6474: warning: =E2=80=98r256=E2=80=99 may be u= sed uninitialized in this function >>> net/bluetooth/mgmt.c:6474: warning: =E2=80=98h256=E2=80=99 may be u= sed uninitialized in this function >>> net/bluetooth/mgmt.c:6474: warning: =E2=80=98r192=E2=80=99 may be u= sed uninitialized in this function >>> net/bluetooth/mgmt.c:6474: warning: =E2=80=98h192=E2=80=99 may be u= sed uninitialized in this function >>>=20 >>> 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. >>=20 >> 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 se= ems to be just plain stupid. On a gcc 4.9, I am not seeing these for ex= ample. >=20 > gcc 4.1.2. As there were too many false positives, these warnings wer= e > disabled in later versions (throwing away the children with the bad w= ater). >=20 > 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 po= sitive. And I have been looking at this particular code for a warning t= hat was valid, but we missed initially. But these warnings that you are= fixing are clearly false positive. If this only happens with an old compiler version, I would tend to leav= e the code as is. Then again, what is the general preferred approach he= re? Regards Marcel