From owner-freebsd-bugs@FreeBSD.ORG  Sat Apr  3 01:00:56 2004
Return-Path: <owner-freebsd-bugs@FreeBSD.ORG>
Delivered-To: freebsd-bugs@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 8138F16A4CE
	for <freebsd-bugs@FreeBSD.ORG>; Sat,  3 Apr 2004 01:00:56 -0800 (PST)
Received: from VARK.homeunix.com (adsl-69-104-80-69.dsl.pltn13.pacbell.net
	[69.104.80.69])	by mx1.FreeBSD.org (Postfix) with ESMTP id 4FF8443D58
	for <freebsd-bugs@FreeBSD.ORG>; Sat,  3 Apr 2004 01:00:56 -0800 (PST)
	(envelope-from das@FreeBSD.ORG)
Received: from VARK.homeunix.com (localhost [127.0.0.1])
	by VARK.homeunix.com (8.12.11/8.12.10) with ESMTP id i3390CCb018781;
	Sat, 3 Apr 2004 01:00:12 -0800 (PST)
	(envelope-from das@FreeBSD.ORG)
Received: (from das@localhost)
	by VARK.homeunix.com (8.12.11/8.12.10/Submit) id i3390C57018780;
	Sat, 3 Apr 2004 01:00:12 -0800 (PST)
	(envelope-from das@FreeBSD.ORG)
Date: Sat, 3 Apr 2004 01:00:12 -0800
From: David Schultz <das@FreeBSD.ORG>
To: Valentin Nechayev <netch@ivb.nn.kiev.ua>
Message-ID: <20040403090012.GA18694@VARK.homeunix.com>
Mail-Followup-To: Valentin Nechayev <netch@ivb.nn.kiev.ua>,
	freebsd-bugs@FreeBSD.ORG
References: <200403271940.i2RJeBgg052032@freefall.freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200403271940.i2RJeBgg052032@freefall.freebsd.org>
cc: freebsd-bugs@FreeBSD.ORG
Subject: Re: gnu/62782: strlcpy performance problem
X-BeenThere: freebsd-bugs@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Bug reports <freebsd-bugs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-bugs>,
	<mailto:freebsd-bugs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-bugs>
List-Post: <mailto:freebsd-bugs@freebsd.org>
List-Help: <mailto:freebsd-bugs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-bugs>,
	<mailto:freebsd-bugs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Apr 2004 09:00:56 -0000

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@ivb.nn.kiev.ua>
> To: chc <chc@mail2000.com.tw>
> Cc: freebsd-gnats-submit@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.