Re: [sdcc-devel] built-in strncpy()

[Maarten B. <sou...@ds...>]

Hi Philipp,

I only payed some attention to absolute code size and execution speed of
the generated asm, not relative to function call overhead. The main goal
was generating correct code.

But looking into this some more, I suggest to keep it in. The extra size
is not too big: +6 bytes. When the function appears only once linking in
the library will give larger code due to function overhead (at least 9
bytes). I also expect most strncpy instances use a small length where the
overhead becomes significant in the execution time. And the currently
generated library implementation is really not optimal.

Btw. I was surprised that it passed gcc-torture-execute-string-opt-5.c as
it tests for this bug. But apparently there it doesn't use the built-in
version.

Thanks for asking before ditching my contribution anyway. I'll leave the
final decision to you.

Maarten

> Dear Maarten,
>
> you recently fixed a bug in the built-in strncpy() in the z80-related
> ports. However the fix made the code generated for this bult-in function
> quite a bit longer. Usually we only have built-in functions where the
> generated code is not much longer than the function call overhead would
> be. Is it really worth keeping strncpy() around as a built-in function?
> Should we just use the library function instead?
>
> Philipp