[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.071 / U:0.980 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site