Re: [PATCH v2] prefer memcpy() over strcpy()

[James <tirtajames45@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1973 bytes --]

On Tue, Mar 26, 2024, 7:42 AM Oliver Kiddle <opk@zsh.org> wrote:

> On 18 Mar, James Tirta Halim wrote:
> > Add zmemcpyz(), a memcpy() that nul-terminates the destination string.
> > This is meant to be used when we have the strlen() of the string.
>
> I was hoping someone else would review this. It touches on areas I'm
> unsure of and I needed to check on how static inline differs between C
> and C++.
>
> > We should prefer memcpy() when we know the length because it most libc
> > implementations provide an assembly implementation of memcpy but maybe
> > not strcpy(). Even if it is implemented in assembly, memcpy() is likely
> > to be faster than strcpy() since as the loop condition strcpy() needs
> > to check for zeros in SRC, whereas memcpy() can just decrement the size.
>
> Have you verified that this does actually have a positive effect on
> performance?

Musl doesn't provide an assembly implementation for strcpy, so it should be
as fast as asm memcpy is to C memcpy. Glibc does, so performance difference
is theoretical.

> If we're bothering to do this, I'd also assume that mempcpy() might also
> be a teany tiny bit faster on systems that support it. Autoconf should
> make that easy to check for.
>
Sure.

> > --- a/Src/zsh.h
>
> > +#include <stddef.h>
> > +#include <string.h>
>
> Currently there are no #includes in zsh.h so I'd be uneasy about adding
> some without being fully sure I understood the reasoning behind the
> current setup for prototypes and headers. For now, it is only used in
> string.c. It'd be easier to add there only for now and address our
> use of inline functions separately. The makepro.awk mechanism largely
> predates inline functions so I'm not quite sure how we can arrange for
> inline functions to appear in full in string.epro or whatever zsh.mdh
> includes. Anyone know?
>
I think it would be better to make it a macro for now. The function call
overhead may become a pessimization for small strings.

> Oliver
>

[-- Attachment #2: Type: text/html, Size: 3006 bytes --]