Messages in this thread | | | Date | Sun, 11 Feb 2024 12:08:14 +0100 | From | Willy Tarreau <> | Subject | Re: [PATCH 3/4] tools/nolibc: Fix strlcpy() return code and size usage |
| |
Hi Rodrigo,
On Mon, Jan 29, 2024 at 03:15:15PM +0100, Rodrigo Campos wrote: > The return code should always be strlen(src), and we should copy at most > size-1 bytes. > > While we are there, make sure to null-terminate the dst buffer. > > Signed-off-by: Rodrigo Campos <rodrigo@sdfg.com.ar> > --- > tools/include/nolibc/string.h | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/tools/include/nolibc/string.h b/tools/include/nolibc/string.h > index b2149e1342a8..e4bc0302967d 100644 > --- a/tools/include/nolibc/string.h > +++ b/tools/include/nolibc/string.h > @@ -212,15 +212,16 @@ size_t strlcpy(char *dst, const char *src, size_t size) > size_t len; > char c; > > - for (len = 0;;) { > + for (len = 0; len < size; len++) { > c = src[len]; > - if (len < size) > + if (len < size - 1) > dst[len] = c; > + if (len == size - 1) > + dst[len] = '\0'; > if (!c) > break; > - len++; > } > - return len; > + return strlen(src); > }
It's good, but for the same reason as the previous one, I'm getting smaller code by doing less in the loop. Also calling strlen() here looks expensive, I'm seeing that the compiler inlined it nevertheless and did it in a dep-optimized way due to the asm statement. That results in 67 bytes total while a simpler version gives 47.
If I explicitly mark strlen() __attribute__((noinline)) that prevents it from doing so starting with gcc-10, where it correctly places a jump from strlcpy() to strlen() and ends up with 50 bytes (vs 44 for the alt one). The other one I can propose is directly derived from the other strlcat() variant, which first performs the copy and starts to count:
size_t strlcpy(char *dst, const char *src, size_t size) { size_t len;
for (len = 0; len < size; len++) { if (!(dst[len] = src[len])) return len; }
/* end of src not found before size */ if (size) dst[size - 1] = '\0';
while (src[len]) len++;
return len; }
Just let me know what you think. And I think we should explicitly mark strlen() and the few other ones we're marking weak as noinline so that the compiler perfers a call there to inlining. Well, registers clobbering might not always be worth, but given that strlen() alone provides some savings I think it's still interesting.
Thanks, Willy
| |