Re: New Defects reported by Coverity Scan for RTEMS-Newlib

[Joel Sherrill <joel@rtems.org>]

On Tue, Mar 1, 2022, 1:31 PM C Howland <cc1964t@gmail.com> wrote:

> >
> > ------------------------------
> > *From:* Newlib <newlib-bounces+craig.howland=caci.com@sourceware.org> on
> > behalf of Joel Sherrill <joel@rtems.org>
> > *Sent:* Tuesday, March 1, 2022 7:59 AM
> > *To:* Newlib <newlib@sourceware.org>
> > *Subject:* Fwd: New Defects reported by Coverity Scan for RTEMS-Newlib
> >
> >
> >
> > Hi
> >
> > The RTEMS Projects runs Coverity Scan when Newlib changes.
> >
> > Not sure who committed something that triggered these but overnight 6 new
> > defects showed up. Most look to be NULL dereferences.
> >
> > --joel
> >
> > ---------- Forwarded message ---------
> > From: <scan-admin@coverity.com>
> > Date: Tue, Mar 1, 2022, 12:25 AM
> > Subject: New Defects reported by Coverity Scan for RTEMS-Newlib
> > To: <joel.sherrill@gmail.com>
> >
> >
> > Hi,
> >
> > Please find the latest report on new defect(s) introduced to RTEMS-Newlib
> > found with Coverity Scan.
> >
> > 6 new defect(s) introduced to RTEMS-Newlib found with Coverity Scan.
> >
> >
> > New defect(s) Reported-by: Coverity Scan
> > Showing 6 of 6 defect(s)
> >
> >
> > ** CID 387497:    (FORWARD_NULL)
> >
> >
> /home/joel/rtems-cron-coverity/sourceware-mirror-newlib-cygwin/newlib/libc/stdio/asiprintf.c:
> > 46 in _asiprintf_r()
> >
> >
> >
> >
> ________________________________________________________________________________________________________
> > *** CID 387497:    (FORWARD_NULL)
> >
> >
> /home/joel/rtems-cron-coverity/sourceware-mirror-newlib-cygwin/newlib/libc/stdio/asiprintf.c:
> > 46 in _asiprintf_r()
> > 40       f._file = -1;  /* No file. */
> > 41       va_start (ap, fmt);
> > 42       ret = _svfiprintf_r (ptr, &f, fmt, ap);
> > 43       va_end (ap);
> > 44       if (ret >= 0)
> > 45         {
> > >>>     CID 387497:    (FORWARD_NULL)
> > >>>     Dereferencing null pointer "f._p".
> > 46           *f._p = 0;
> > 47           *strp = (char *) f._bf._base;
> > 48         }
> > 49       return (ret);
> > 50     }
> > 51
> >
>
> Joel:
>      In a quick look nothing related to these has changed.  And looking
> specifically at this one complaint (which looks to be representative of all
> the rest), the complaint is spurious.  The check for the return being >= 0
> means that _p has been set by the called function.
>

Weird. Shouldn't have popped up suddenly.

Just passing along. If you don't pay attention when they are new, they age
badly.

Thanks.


                                    Craig
>