<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 12, 2020 at 9:43 AM Aschref Ben-Thabet <<a href="mailto:aschref.ben-thabet@embedded-brains.de">aschref.ben-thabet@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">Hello joel, Gedare,<br>
<br>
i think in this way , we may use Strdup/ Strrndup instead of memcpy to <br>
guarantee the copy of null terminated String.<br>
in this case we don't need to allocate memory, since Strdup do this one.<br></blockquote><div><br></div><div>memcpy() copies bytes from one location to another and str*dup() creates</div><div>a second copy with a newly allocated location. I still don't see the functional</div><div>equivalence to do a replacement.</div><div><br></div><div>And we still haven't seen the compiler report from the original code that we</div><div>are trying to address. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
i m unconscious with the line #224 key.dsize = sizeof( test_strings )<br>
then i have a doubt if it is correctly defined or we take in this case <br>
the size of pointer instead of the size of an array.<br></blockquote><div><br></div><div>That is a common programming mistake. If that's what is happening,</div><div>then the sizeof() probably should be strlen() or the string needs to be</div><div>declared with a fixed size and the same constant used on the right hand</div><div>size.</div><div><br></div><div>Sorry. I haven't seen the actual warning and the fix doesn't seem like</div><div>the right way to manage strings.</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>
Best regards,<br>
Aschref<br>
<br>
On 8/12/20 3:55 PM, Joel Sherrill wrote:<br>
> <br>
> <br>
> On Wed, Aug 12, 2020 at 8:41 AM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a> <br>
> <mailto:<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>>> wrote:<br>
> <br>
> On Wed, Aug 12, 2020 at 7:03 AM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a><br>
> <mailto:<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Wed, Aug 12, 2020 at 7:07 AM Aschref Ben-Thabet<br>
> <<a href="mailto:aschref.ben-thabet@embedded-brains.de" target="_blank">aschref.ben-thabet@embedded-brains.de</a><br>
> <mailto:<a href="mailto:aschref.ben-thabet@embedded-brains.de" target="_blank">aschref.ben-thabet@embedded-brains.de</a>>> wrote:<br>
> >><br>
> >> From: Aschref Ben Thabet <<a href="mailto:aschref.ben-thabet@embedded-brains.de" target="_blank">aschref.ben-thabet@embedded-brains.de</a><br>
> <mailto:<a href="mailto:aschref.ben-thabet@embedded-brains.de" target="_blank">aschref.ben-thabet@embedded-brains.de</a>>><br>
> >><br>
> >> replace strncpy with memcpy to silence this warning and free the<br>
> >> allocated memory block.<br>
> ><br>
> ><br>
> > I don't see a call to strncpy being replaced. Maybe I need<br>
> coffee. I see an<br>
> > RTEMS test assert strcmp.<br>
> ><br>
> > Silence what warning?<br>
> ><br>
> > I do not think it is appropriate to replace str*cpy with memcpy.<br>
> What is the warning?<br>
> ><br>
> <br>
> We had this discussion on a previous thread, start from<br>
> <a href="https://lists.rtems.org/pipermail/devel/2020-July/061008.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-July/061008.html</a><br>
> <br>
> <br>
> I know and I didn't like it then but couldn't put my finger on it. Plus<br>
> some of the warnings have been in psxhdr tests and my concern is<br>
> lower because they never get executed.<br>
> <br>
> Using memcpy() violates the contract on how strings are to be processed.<br>
> There is no assurance we end up with NULL terminated strings. We have<br>
> seen string warnings with Coverity and other scanners before and addressed<br>
> them without abandoning str*(). Why now?<br>
> <br>
> What is the warning and what is the proper fix? Eliminating use of string<br>
> operations is heavy handed and introduces other risks.<br>
> <br>
> We haven't seen the actual warning and alternative solutions.<br>
> <br>
> FWIW I've had discussions with aviation safety reviewers and, to my<br>
> surprise, strcpy() is actually OK to use sometimes. I asked because<br>
> strncpy() is not in the FACE Technical Standard profiles because I don't <br>
> think<br>
> it was not in POSIX 2001 which is what the baseline API sets were based on.<br>
> <br>
> --joel<br>
> <br>
> <br>
> <br>
> <br>
> >> ---<br>
> >> testsuites/psxtests/psxndbm01/init.c | 3 ++-<br>
> >> 1 file changed, 2 insertions(+), 1 deletion(-)<br>
> >><br>
> >> diff --git a/testsuites/psxtests/psxndbm01/init.c<br>
> b/testsuites/psxtests/psxndbm01/init.c<br>
> >> index b524aff0df..658af58df3 100644<br>
> >> --- a/testsuites/psxtests/psxndbm01/init.c<br>
> >> +++ b/testsuites/psxtests/psxndbm01/init.c<br>
> >> @@ -216,11 +216,12 @@ rtems_task Init(rtems_task_argument ignored)<br>
> >> get_phone_no = dbm_fetch( db, name2 );<br>
> >> rtems_test_assert( strcmp( (const char*)get_phone_no.dptr,<br>
> PHONE_NO2 ) == 0 );<br>
> >><br>
> >> - puts( "Fetch non-existing record and confirm error." );<br>
> >> + puts( "Fetch non-existing record and confirm error." );<br>
> ><br>
> ><br>
> > I don't see a change here.<br>
> ><br>
> > And while you are here non-existing isn't a word. It should be<br>
> "nonexistent"<br>
> ><br>
> >><br>
> >> test_strings = (char*)malloc(6);<br>
> >> memcpy( test_strings, "Hello", 5 );<br>
> >><br>
> >> test_strings[5] = '\0';<br>
> >> + free(test_strings);<br>
> >><br>
> >> /* The data pointed by test_string is now pointed by key.dptr */<br>
> >> key.dptr = test_strings;<br>
> >> --<br>
> >> 2.26.2<br>
> >><br>
> >> _______________________________________________<br>
> >> devel mailing list<br>
> >> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a> <mailto:<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><br>
> ><br>
> > _______________________________________________<br>
> > devel mailing list<br>
> > <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a> <mailto:<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><br>
> <br>
</blockquote></div></div>