From: "Zeng, Star" <star.zeng@intel.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Laszlo Ersek <lersek@redhat.com>,
"Gao, Liming" <liming.gao@intel.com>,
"Bi, Dandan" <dandan.bi@intel.com>,
"Wu, Hao A" <hao.a.wu@intel.com>
Cc: "Ni, Ruiyu" <ruiyu.ni@intel.com>,
"Dong, Eric" <eric.dong@intel.com>,
edk2-devel-01 <edk2-devel@lists.01.org>
Subject: Re: [PATCH 2/2] MdeModulePkg/UdfDxe: suppress incorrect compiler warning in ReadFile()
Date: Thu, 14 Sep 2017 01:20:34 +0000 [thread overview]
Message-ID: <0C09AFA07DD0434D9E2A0C6AEB0483103B94E290@SHSMSX151.ccr.corp.intel.com> (raw)
In-Reply-To: <0C09AFA07DD0434D9E2A0C6AEB0483103B94A227@SHSMSX151.ccr.corp.intel.com>
Seemingly, VS has similar issue with GCC.
VS2010/VS2012 still have the building failures below after this patch. :(
edk2\mdemodulepkg\universal\disk\udfdxe\filesystemoperations.c(1083) : error C2220: warning treated as error - no 'executable' file generated
edk2\mdemodulepkg\universal\disk\udfdxe\filesystemoperations.c(1083) : warning C4701: potentially uninitialized local variable 'FilePosition' used
edk2\mdemodulepkg\universal\disk\udfdxe\filesystemoperations.c(1078) : warning C4701: potentially uninitialized local variable 'FinishedSeeking' used
edk2\mdemodulepkg\universal\disk\udfdxe\filesystemoperations.c(1167) : warning C4701: potentially uninitialized local variable 'Data' used
edk2\mdemodulepkg\universal\disk\udfdxe\filesystemoperations.c(1167) : warning C4703: potentially uninitialized local pointer variable 'Data' used
Liming, Dandan and Hao,
Do you remember how we fix this kind of false alarm before?
Just initialize the variable at the beginning of the function?
Thanks,
Star
-----Original Message-----
From: Zeng, Star
Sent: Thursday, September 14, 2017 8:43 AM
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Laszlo Ersek <lersek@redhat.com>
Cc: Ni, Ruiyu <ruiyu.ni@intel.com>; Dong, Eric <eric.dong@intel.com>; edk2-devel-01 <edk2-devel@lists.01.org>; Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.com>
Subject: RE: [edk2] [PATCH 2/2] MdeModulePkg/UdfDxe: suppress incorrect compiler warning in ReadFile()
Comparing adding workaround in code with suppressing it in *OLD* version GCCs, 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 <lersek@redhat.com>
Cc: Ni, Ruiyu <ruiyu.ni@intel.com>; Dong, Eric <eric.dong@intel.com>; edk2-devel-01 <edk2-devel@lists.01.org>; Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.com>
Subject: Re: [edk2] [PATCH 2/2] MdeModulePkg/UdfDxe: suppress incorrect compiler warning in ReadFile()
On 13 September 2017 at 11:49, Laszlo Ersek <lersek@redhat.com> 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 about 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 specific version of GCC for this kind of false alarm?
>>
>>
>> ProcessorBind.h:
>> #if defined(_MSC_EXTENSIONS)
>>
>> ...
>>
>> #if _MSC_VER == 1800 || _MSC_VER == 1900
>>
>> //
>> // Disable these warnings for VS2013.
>> //
>>
>> //
>> // This warning is for potentially uninitialized local variable, and
>> it may cause false // positive issues in VS2013 and VS2015 build //
>> #pragma warning ( disable : 4701 )
>>
>> //
>> // This warning is for potentially uninitialized local pointer
>> variable, and it may cause // false positive issues in VS2013 and
>> VS2015 build // #pragma warning ( disable : 4703 )
>>
>> #endif
>>
>> #endif
>
> I think starting with gcc-4.6, gcc supports the "diagnostics" pragma,
> which can be used to suppress warnings.
>
> Unfortunately, there's no pragma to suppress *only* the incorrect
> warnings :) So if we set the pragma, we could lose even those warnings
> 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 lose any coverage by doing so.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
next prev parent reply other threads:[~2017-09-14 1:17 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-12 22:26 [PATCH 0/2] MdeModulePkg: UDF fixes and cleanups, round 2 Laszlo Ersek
2017-09-12 22:26 ` [PATCH 1/2] MdeModulePkg/UdfDxe: reject reserved values in ICB.Flags[2:0] Laszlo Ersek
2017-09-13 2:26 ` Ni, Ruiyu
2017-09-13 6:35 ` Zeng, Star
2017-09-12 22:26 ` [PATCH 2/2] MdeModulePkg/UdfDxe: suppress incorrect compiler warning in ReadFile() Laszlo Ersek
2017-09-13 6:33 ` Zeng, Star
2017-09-13 6:43 ` Zeng, Star
2017-09-13 18:49 ` Laszlo Ersek
2017-09-13 18:52 ` Ard Biesheuvel
2017-09-14 0:42 ` Zeng, Star
2017-09-14 1:20 ` Zeng, Star [this message]
2017-09-14 1:30 ` Gao, Liming
2017-09-14 8:19 ` Laszlo Ersek
2017-09-14 8:53 ` Zeng, Star
2017-09-14 8:17 ` Laszlo Ersek
2017-09-14 8:50 ` Zeng, Star
2017-09-14 9:01 ` Laszlo Ersek
2017-09-13 13:42 ` [PATCH 0/2] MdeModulePkg: UDF fixes and cleanups, round 2 Paulo Alcantara
2017-09-13 22:08 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0C09AFA07DD0434D9E2A0C6AEB0483103B94E290@SHSMSX151.ccr.corp.intel.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox