Coverity false positive pattern

[Joel Sherrill]

On Tue, Feb 25, 2020, 3:00 PM Gedare Bloom <gedare at rtems.org> wrote:

> On Tue, Feb 25, 2020 at 9:38 AM suyash singh <suyashsingh234 at gmail.com>
> wrote:
> >
> > Yes it is showing for unused values
> >
> > For example at line 262 in
> https://scan5.coverity.com/reports.htm#v53137/p10069/fileInstanceId=164938787&defectInstanceId=45953284&mergedDefectId=1399751
> >
> That appears to be legitimate. Analysis now has to be made whether the
> value written should have been consumed somewhere, or if it is OK to
> remove the assignment.
>

Thanks for the analysis but please remember that Scan requires an account.
When asking about a specific piece of code, it is better to link to the
lone using git.rtems.org.

I am out of town and on my phone. I could probably comment looking at git,
but not with a scan link. That site is way too busy for a small screen. :)

--joel

>
> > On Tue, Feb 25, 2020 at 9:21 PM Joel Sherrill <joel at rtems.org> wrote:
> >>
> >>
> >>
> >> On Tue, Feb 25, 2020 at 9:47 AM suyash singh <suyashsingh234 at gmail.com>
> wrote:
> >>>
> >>> Coverity shows value_overwrite errors for variables which are
> reassigned new values. What should be the procedure to prevent these?
> >>
> >>
> >> When I have seen these in the past, they indicate a case where a
> variable is assigned
> >> and assigned later without the first value being used. Is this what you
> are seeing?
> >>
> >> What file and line?
> >>
> >> We sometimes assign a variable 0 when declaring it to avoid gcc warning
> about used
> >> before initialized. It wouldn't surprise me if Scan didn't always like
> that.
> >>
> >> --joel
> >>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> devel mailing list
> >>> devel at rtems.org
> >>> http://lists.rtems.org/mailman/listinfo/devel
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200225/dafb91f4/attachment.html>