www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/12/09/09:52:02.1

Date: Wed, 9 Dec 1998 16:52:15 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Freddie Schwenke <freddie DOT schwenke2 AT sanlam DOT co DOT za>
cc: djgpp AT delorie DOT com
Subject: Re: memcpy() vs memmove()
In-Reply-To: <74lrv4$k9i$1@hermes.is.co.za>
Message-ID: <Pine.SUN.3.91.981209164512.10851C-100000@is>
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com

On Wed, 9 Dec 1998, Freddie Schwenke wrote:

> I'm quite aware that there is a differrence between the two functions.  I
> actually want to abuse the memcpy() function to replicate one ore more bytes
> throughout a string.

You CANNOT use `memcpy' to copy overlapping regions.  You just can't.

The reason is that `memcpy' uses an algorithm that fails to do the right 
thing when the source and the target regions overlap.  You must use 
`memmove' in that case.

> The problem is that memcpy() only works while the length is less that 
> 16.  WHY??? 

This is just one of the manifestations of the failure I was talking 
about.  If you *really* want to know the exact reason, look at the 
assembly code of `memcpy'.

But I don't think the exact reason is relevant, or even interesting.  
Just don't use `memcpy' when the regions overlap, it doesn't work in 
these cases.

> Is this a C thing or a DJGPP thing?  In MS Visual C++ apparently there is no
> difference betwee the two functions!!!

It depends on how the library was written, obviously.  In addition, GCC 
sometimes produces inline assembly code instead of generating a call to 
`memcpy' from the library, so the compiler also matters.

But the ANSI standard explicitly says that `memcpy' behavior for 
overlapping regions is ``undefined'' (read: anything can happen).  So I 
guess you could say it's ``a C thing''.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019