<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 15, 2020 at 12:24 PM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 15/10/2020 15:06, Frank Kühndel wrote:<br>
<br>
> On 10/15/20 2:09 PM, Sebastian Huber wrote:<br>
>>> From: Frank Kühndel<<a href="mailto:frank.kuehndel@embedded-brains.de" target="_blank">frank.kuehndel@embedded-brains.de</a>><br>
>>><br>
>>> The compiler warning was:<br>
>>><br>
>>> ../../../cpukit/libmisc/rtems-fdt/rtems-fdt.c:267:5: warning:<br>
>>> 'strncpy' specified bound depends on the length of the source argument<br>
>>>     267 |     strncpy(path, name, namelen);<br>
>>>         |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
>>><br>
>>> It turns out that the `strncpy()` nor the buffer `path` is needed when<br>
>>> one uses `strncmp()` instead of `strcmp()`. This needs some change to<br>
>>> the algorithm but has the advantage that `name` is never truncated<br>
>>> to the size of the buffer `path`.<br>
>> Does it help to use bsearch() to simplify this code further?<br>
> Nice! I did not even know (or remember about) bsearch().<br>
><br>
> No, it wont help. bsearch() works on "similar" objects (e.g. two<br>
> strings). The function I modified searches a string in an array of<br>
> 'rtems_fdt_index_entry' objects. To make that work, one must create a<br>
> dummy 'rtems_fdt_index_entry' containing that string.<br>
><br>
> Moreover, there remains the problem that the 'name' string has an<br>
> artificially restricted length which must be convoyed to the 'compar()'<br>
> function used by 'bseach()'.<br>
><br>
> Finally, rtems-fdt.c is - most likely - dead code. So, I would end up<br>
> spending my time on brushing up dead code.<br>
<br>
Ok, thanks for having a look at this. I checked in the patch as is.<br>
<br>
This was the last warning in the architecture-independent part (except <br>
the old network stack).<br></blockquote><div><br></div><div>Do any of these show up in Coverity? I can't run it on the master due to</div><div>some unrecognized gcc version issue I think.</div><div><br></div><div>If these areas show up as Coverity issues, it would be nice if the patches</div><div>are applied to 5 so we can verify the fix makes Coverity happy.</div><div><br></div><div>Yes. Eventually we will be able to run on the master but we get quite</div><div>limited (no) support from Coverity so no idea when.</div><div><br></div><div>--joel </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>