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

[Oliver Kiddle <opk@xxxxxxx>]

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?

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.

> --- 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?

Oliver