lkml.org 
[lkml]   [2024]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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

    \
     
     \ /
      Last update: 2024-05-27 14:57    [W:6.945 / U:0.376 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site