public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Michael D Kinney" <michael.d.kinney@intel.com>
To: Pedro Falcato <pedro.falcato@gmail.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: "Andrew (EFI) Fish" <afish@apple.com>,
	"wangliu@iscas.ac.cn" <wangliu@iscas.ac.cn>,
	"Kinney, Michael D" <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG?
Date: Thu, 17 Aug 2023 20:50:49 +0000	[thread overview]
Message-ID: <CO1PR11MB4929D54A1F98E09CA0CBCC85D21AA@CO1PR11MB4929.namprd11.prod.outlook.com> (raw)
In-Reply-To: <CAKbZUD1GNC-XW6A1+X5tOskKQVPEVOwvp7mfb+OO-mzAi91X=w@mail.gmail.com>

Hi Pedro,

I agree that compiler and static analysis absolutely do get false positive
results.

When we see these, we have a choice to make
* Document for all consumers that a specific tool has a false positive and
  we can all safely ignore the report. This is challenging to communicate
  these to all downstream consumers.
* Disable warnings/errors if the report is from a compiler.
* Do a small source code change to address the false positive.

We have a history of doing the last 2.

I would also point out that when these false positives are generated,
they tend to be in larger, more complex functions.  Another option 
to consider is to refactor the code into smaller parts so the code
is both easier to maintain/support and improve the static analysis
results with fewer false positives.

Each report needs to be handled on a case by case basis.

Mike



> -----Original Message-----
> From: Pedro Falcato <pedro.falcato@gmail.com>
> Sent: Thursday, August 17, 2023 1:18 PM
> To: devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: Andrew (EFI) Fish <afish@apple.com>; wangliu@iscas.ac.cn
> Subject: Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG?
> 
> On Thu, Aug 17, 2023 at 9:00 PM Michael D Kinney
> <michael.d.kinney@intel.com> wrote:
> >
> > I am surprised this same GCC error is not being seen for other CPU
> archs.
> >
> >
> >
> > The simple fix is to this specific issue is to initialize CommandLine
> to NULL at the beginning of the function.
> 
> The correct fix here is to -Wno-error=maybe-uninitialized. This
> warning is error prone and IIRC already disabled in the Linux kernel.
> Heck, Wno-error=uninitialized wouldn't be a bad idea either, we
> recently uncovered a GCC bug on it
> (https://lore.kernel.org/all/20230719190045.4007391-1-arnd@kernel.org/).
> >
> > We have observed that compilers continue to add more and more static
> analysis like features over time.  Code that compiled without
> warnings/errors with an earlier compiler may generate warnings/errors on
> a newer compiler.  This looks like an example of this case.
> Well, in this case the static analysis is wrong :)
> 
> --
> Pedro


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107840): https://edk2.groups.io/g/devel/message/107840
Mute This Topic: https://groups.io/mt/100663199/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



  reply	other threads:[~2023-08-17 20:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-10 10:44 [edk2-devel] Can RELEASE target disable -Werror CC_FLAG? 汪流
2023-08-10 13:50 ` Andrew Fish via groups.io
2023-08-16  7:46   ` 汪流
2023-08-16 17:02     ` Michael D Kinney
2023-08-16 17:41       ` Andrew Fish via groups.io
2023-08-16 17:50         ` Michael D Kinney
2023-08-17  6:30           ` 汪流
2023-08-17 11:45             ` Andrew Fish via groups.io
2023-08-17 20:00               ` Michael D Kinney
2023-08-17 20:17                 ` Pedro Falcato
2023-08-17 20:50                   ` Michael D Kinney [this message]
2023-08-21  7:04               ` 汪流
     [not found]               ` <177D54194984ABD0.15959@groups.io>
2023-08-25 10:25                 ` 汪流

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=CO1PR11MB4929D54A1F98E09CA0CBCC85D21AA@CO1PR11MB4929.namprd11.prod.outlook.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