@oschonrock - looking at the code, this seems to be a hardened version of the original function? Is there a case to include the in the original lib? (Maybe as a new function if there could be backwards compatibility issues)
Interesting to see that the graph is not strictly decreasing — meaning that there were commits that added new strcpy() lines as late as this year, despite the projects' review efforts. 🤔
Nonetheless, congrats on reaching 0%. Is there a plan to prevent calls to "bad" functions from sneaking back in again?
Kevin
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to Kevin • • •curl/lib/curlx/strcopy.c at master · curl/curl
GitHubsuzune
in reply to daniel:// stenberg:// • • •The memcpy() and mempcpy() functions copy len bytes from string src to string dst. If src and dst overlap, the results are not defined.
Shouldn't there be "restrict" in the function type signature?
en.cppreference.com/w/c/langua…
Otherwise: memmove.
restrict type qualifier (since C99) - cppreference.com
en.cppreference.combdf2121cc3334b35b6ecda66e471
in reply to daniel:// stenberg:// • • •Oliver Schönrock
in reply to daniel:// stenberg:// • • •Great stuff. What was the motivation here?
performance (ie copying per se), or security (ie replace with strncopy)
daniel:// stenberg://
in reply to Oliver Schönrock • • •mth
in reply to daniel:// stenberg:// • • •EricJ
in reply to daniel:// stenberg:// • • •Interesting to see that the graph is not strictly decreasing — meaning that there were commits that added new strcpy() lines as late as this year, despite the projects' review efforts. 🤔
Nonetheless, congrats on reaching 0%. Is there a plan to prevent calls to "bad" functions from sneaking back in again?
xzvf | Peter Bohner
in reply to daniel:// stenberg:// • • •