[PATCH] rtems-fdt / shell - Fix string truncation warning

[Joel Sherrill]

On Thu, Oct 15, 2020 at 12:24 PM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 15/10/2020 15:06, Frank Kühndel wrote:
>
> > On 10/15/20 2:09 PM, Sebastian Huber wrote:
> >>> From: Frank Kühndel<frank.kuehndel at embedded-brains.de>
> >>>
> >>> The compiler warning was:
> >>>
> >>> ../../../cpukit/libmisc/rtems-fdt/rtems-fdt.c:267:5: warning:
> >>> 'strncpy' specified bound depends on the length of the source argument
> >>>     267 |     strncpy(path, name, namelen);
> >>>         |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>>
> >>> It turns out that the `strncpy()` nor the buffer `path` is needed when
> >>> one uses `strncmp()` instead of `strcmp()`. This needs some change to
> >>> the algorithm but has the advantage that `name` is never truncated
> >>> to the size of the buffer `path`.
> >> Does it help to use bsearch() to simplify this code further?
> > Nice! I did not even know (or remember about) bsearch().
> >
> > No, it wont help. bsearch() works on "similar" objects (e.g. two
> > strings). The function I modified searches a string in an array of
> > 'rtems_fdt_index_entry' objects. To make that work, one must create a
> > dummy 'rtems_fdt_index_entry' containing that string.
> >
> > Moreover, there remains the problem that the 'name' string has an
> > artificially restricted length which must be convoyed to the 'compar()'
> > function used by 'bseach()'.
> >
> > Finally, rtems-fdt.c is - most likely - dead code. So, I would end up
> > spending my time on brushing up dead code.
>
> Ok, thanks for having a look at this. I checked in the patch as is.
>
> This was the last warning in the architecture-independent part (except
> the old network stack).
>

Do any of these show up in Coverity? I can't run it on the master due to
some unrecognized gcc version issue I think.

If these areas show up as Coverity issues, it would be nice if the patches
are applied to 5 so we can verify the fix makes Coverity happy.

Yes. Eventually we will be able to run on the master but we get quite
limited (no) support from Coverity so no idea when.

--joel

>
> _______________________________________________
> 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/20201015/2a5900c0/attachment.html>