Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:10418 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 25902 invoked by uid 1010); 13 Jun 2004 12:55:38 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 25768 invoked from network); 13 Jun 2004 12:55:37 -0000 Received: from unknown (HELO spawn.leetspeak.org) (217.28.101.185) by pb1.pair.com with SMTP; 13 Jun 2004 12:55:37 -0000 Received: (qmail 30985 invoked from network); 13 Jun 2004 14:56:24 +0200 Received: from p5083bb03.dip.t-dialin.net (HELO ?192.168.1.11?) (cm@80.131.187.3) by molly.zwonet.de with AES256-SHA encrypted SMTP; 13 Jun 2004 14:56:24 +0200 Message-ID: <40CC4EC3.9080407@leetspeak.org> Date: Sun, 13 Jun 2004 14:55:31 +0200 User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Schlossnagle , internals@lists.php.net References: In-Reply-To: X-Enigmail-Version: 0.84.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] str_repeat() patch From: cm@leetspeak.org (Michael Walter) Well, surely memmove() needs an additional branch to check for overlapping, though (the OP was wrong in that memmove() would need a temporary buffer, though - it doesn't, it usually copies from high addres to low in the overlapping case). Cheers, Michael George Schlossnagle wrote: > > On Jun 12, 2004, at 10:27 AM, Alexander Valyalkin wrote: > >> On Fri, 11 Jun 2004 17:00:03 +0200 (CEST), Derick Rethans >> wrote: >> >>> On Fri, 11 Jun 2004, Alexander Valyalkin wrote: >>> >>>> >>>> Read it: >>>> void *memmove(void *s1, const void *s2, size_t n); >>>> If s1 and s2 overlap, all bytes are copied in a preserving manner >>>> (unlike >>>> memcpy()) >>>> >>>> And anwer the question: are s1 and s2 overlap in the str_repeat() ? >>>> Why don't use memcpy() instead of memmove() ? >>> >>> >>> Because it's slower and we're copying to newly allocated memory anyway >>> so things CAN not overlap. Also, your patch is the wrong way around. >>> >> >> Mybe I'm mistaken, but I think, that memmove() looks like that (without >> any error checks): > > > That's not what my glibc sources look like. > > George >