On Sun, May 21, 2006 at 07:48:39PM -0400, Albert Cahalan wrote:
> On 5/21/06, Thomas Dickey <[EMAIL PROTECTED]> wrote:
> >On Sun, May 21, 2006 at 05:09:32PM -0400, Albert Cahalan wrote:
> >>
> >> End result: it acts like bzero() when src==dst
> >
> >hmm - someone should fix that broken implementati
On 5/21/06, Thomas Dickey <[EMAIL PROTECTED]> wrote:
On Sun, May 21, 2006 at 05:09:32PM -0400, Albert Cahalan wrote:
>
> End result: it acts like bzero() when src==dst
hmm - someone should fix that broken implementation of memcpy.
It's damn fast. I like fast libraries, don't you?
The ISO stan
On 5/21/06, Thomas Dickey <[EMAIL PROTECTED]> wrote:
On Sun, May 21, 2006 at 09:20:17AM +0200, Albert Cahalan wrote:
> That is indeed a serious error.
no - it's a stupid but benign error:
source and destination addresses are the same
Consider this entirely reasonable implementation for
On Sun, May 21, 2006 at 05:09:32PM -0400, Albert Cahalan wrote:
>
> End result: it acts like bzero() when src==dst
hmm - someone should fix that broken implementation of memcpy.
bye.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
pgpjoTFMI5DAh.pgp
Description: PGP
On Sun, May 21, 2006 at 09:20:17AM +0200, Albert Cahalan wrote:
> That is indeed a serious error.
no - it's a stupid but benign error:
source and destination addresses are the same
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
pgpDNx8Cac3cT.pgp
Description:
That is indeed a serious error.
Besides going either direction, memcpy doesn't need to work via bytes.
It could use 16-byte vector registers. It could use something like
PowerPC's dcbz instruction, which causes a cache line (of the
destination) to be allocated in an all-zero state rather than fet
6 matches
Mail list logo
