On Tue, Mar 26, 2024, 7:42 AM Oliver Kiddle <
opk@xxxxxxx> 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.