From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 78BF420945BF3 for ; Wed, 13 Sep 2017 17:39:58 -0700 (PDT) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga105.fm.intel.com with ESMTP; 13 Sep 2017 17:42:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,390,1500966000"; d="scan'208";a="151079424" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga005.fm.intel.com with ESMTP; 13 Sep 2017 17:42:56 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 13 Sep 2017 17:42:56 -0700 Received: from shsmsx151.ccr.corp.intel.com ([169.254.3.98]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.168]) with mapi id 14.03.0319.002; Thu, 14 Sep 2017 08:42:54 +0800 From: "Zeng, Star" To: Ard Biesheuvel , Laszlo Ersek CC: "Ni, Ruiyu" , "Dong, Eric" , edk2-devel-01 , "Gao, Liming" , "Zeng, Star" Thread-Topic: [edk2] [PATCH 2/2] MdeModulePkg/UdfDxe: suppress incorrect compiler warning in ReadFile() Thread-Index: AQHTLBYspwdYPe7xxk2VyqRg2zXQbKKyXCZQgAAAteCAAEbqAIAAALaAgADm9jA= Date: Thu, 14 Sep 2017 00:42:53 +0000 Message-ID: <0C09AFA07DD0434D9E2A0C6AEB0483103B94A227@SHSMSX151.ccr.corp.intel.com> References: <20170912222612.14451-1-lersek@redhat.com> <20170912222612.14451-3-lersek@redhat.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B94098B@shsmsx102.ccr.corp.intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B9409E7@shsmsx102.ccr.corp.intel.com> <23e789a8-59df-d67d-fa16-fc70aafb95d7@redhat.com> In-Reply-To: Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [PATCH 2/2] MdeModulePkg/UdfDxe: suppress incorrect compiler warning in ReadFile() X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 00:39:58 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comparing adding workaround in code with suppressing it in *OLD* version GC= Cs, I prefer the latter personally. Thanks, Star -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ard = Biesheuvel Sent: Thursday, September 14, 2017 2:52 AM To: Laszlo Ersek Cc: Ni, Ruiyu ; Dong, Eric ; edk2-= devel-01 ; Gao, Liming ; Zen= g, Star Subject: Re: [edk2] [PATCH 2/2] MdeModulePkg/UdfDxe: suppress incorrect com= piler warning in ReadFile() On 13 September 2017 at 11:49, Laszlo Ersek wrote: > On 09/13/17 08:43, Zeng, Star wrote: >> Beyond the Rb (I do not want to block this patch series), I am curious a= bout one question. >> >> There may be more this kind of workarounds to fix the build failure. >> Is it possible to disable the warning (like below example for VS) for sp= ecific version of GCC for this kind of false alarm? >> >> >> ProcessorBind.h: >> #if defined(_MSC_EXTENSIONS) >> >> ... >> >> #if _MSC_VER =3D=3D 1800 || _MSC_VER =3D=3D 1900 >> >> // >> // Disable these warnings for VS2013. >> // >> >> // >> // This warning is for potentially uninitialized local variable, and=20 >> it may cause false // positive issues in VS2013 and VS2015 build //=20 >> #pragma warning ( disable : 4701 ) >> >> // >> // This warning is for potentially uninitialized local pointer=20 >> variable, and it may cause // false positive issues in VS2013 and=20 >> VS2015 build // #pragma warning ( disable : 4703 ) >> >> #endif >> >> #endif > > I think starting with gcc-4.6, gcc supports the "diagnostics" pragma,=20 > which can be used to suppress warnings. > > Unfortunately, there's no pragma to suppress *only* the incorrect=20 > warnings :) So if we set the pragma, we could lose even those warnings=20 > that point out real bugs. > That applies to the VS case as well. But I think doing this for older GCCs = is fine, most EDK2 developers use a newer version anyway, so we will not lo= se any coverage by doing so. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel