gnu/62782: strlcpy performance problem

[David Schultz]

On Sat, Mar 27, 2004, Valentin Nechayev wrote:
> The following reply was made to PR gnu/62782; it has been noted by GNATS.
> 
> From: Valentin Nechayev <netch at ivb.nn.kiev.ua>
> To: chc <chc at mail2000.com.tw>
> Cc: freebsd-gnats-submit at freebsd.org
> Subject: Re: gnu/62782: strlcpy performance problem
> Date: Sat, 27 Mar 2004 21:26:10 +0200
> 
>   Fri, Feb 13, 2004 at 02:30:21, chc (chc) wrote about "gnu/62782: strlcpy performance problem": 
>  
>  c>      while (*s++);            /* performance problem when src is mmap pointer */
>  c> Mmap a big file which is above 500M and use strlcpy. I found it was very slow.        
>  
>  As mapping is on per-page basis, any implementation of per-char scanning
>  (as required by C-styled string copy) will be much faster than page fault
>  interrupt. So your problem isn't strlcpy slowness, but bad program design:
>  you should not use nul-terminated strings for this task.
>  
>  PR is already closed, but I want add my $0.05 to clarify that it isn't
>  one function problem, but conceptual problem (and strncpy() can't fix it,
>  but can only aggravate). Redesign your program.

Not quite.  The problem is that the strlcpy() interface is defined
to return the total length of the source string regardless of the
amount actually copied.  Therefore, unlike strncpy(), strlcpy()
must scan until it reaches a terminating null.  The line the
original submitter complained about implements this functionality.