[lkml]   [2003]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [TRIVIAL] kstrdup
    Richard B. Johnson wrote:
    > On Fri, 18 Apr 2003, Jeff Garzik wrote:
    >>Linus Torvalds wrote:
    >>>On Fri, 18 Apr 2003, Jeff Garzik wrote:
    >>>>You should save the strlen result to a temp var, and then s/strcpy/memcpy/
    >>>No, you should just not do this. I don't see the point.
    >>strcpy has a test for each byte of its contents, and memcpy doesn't.
    >>Why search 's' for NULL twice?
    >> Jeff
    > Because it doesn't. strcpy() is usually implimented by getting
    > the string-length, using the same code sequence as strlen(), then
    > using the same code sequence as memcpy(), but copying the null-byte
    > as well. The check for the null-byte is done in the length routine.
    > If you do a memcpy(a, b, strlen(b));, then you are making two
    > procedure calls and dirtying the cache twice..

    Wrong, because we have to call strlen _anyway_, to provide the size to

    > A typical Intel procedure, stripped of the push/pops to save
    > registers is here....

    That's kinda cute. Why not submit a patch to the strcpy implementation
    in include/asm-i386/string.h? :) Ours is shorter, but does have a jump:
    "testb %%al,%%al\n\t"
    "jne 1b"

    Which is better? I don't know; I'm still learning the performance
    eccentricities of x86 insns on various processors.

    Related x86 question: if the memory buffer is not dword-aligned, is
    'rep movsl' the best idea? On RISC it's usually smarter to unroll the
    head of the loop to avoid unaligned accesses; but from reading x86 asm
    code in the kernel, nobody seems to care about that. Is the
    unaligned-access penalty so small that the increased code size of the
    head-unroll is never worth it?

    > A lot of persons who are unfamiliar with tools other than 'C' think
    > that strcpy() is made like this:
    > while(*dsp++ = *src++)
    > ;

    In fact, that's basically the kernel's non-arch-specific implementation :)


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:34    [W:0.023 / U:1.988 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site