Path: utzoo!utgpu!water!watmath!clyde!rutgers!uwvax!oddjob!gargoyle!ihnp4!alberta!ncc!van-bc!sklpc!skl
From: skl@sklpc.vnet.van-bc.UUCP (Samuel Lam)
Newsgroups: comp.sys.ibm.pc
Subject: Re: bug in Turbo C 1.5
Summary: It's NOT a bug, but a feature.  See the README file for version 1.5.
Keywords: Turbo-C Bug Feature memcpy()
Message-ID: <880125222135@sklpc.vnet.van-bc.UUCP>
Date: 26 Jan 88 06:21:35 GMT
References: <5298@cit-vax.Caltech.Edu>
Reply-To: skl@sklpc.vnet.van-bc.UUCP (Samuel Lam)
Lines: 27

> To the best of my recollection, I don't recall having seen any 
> bug reports so far for Turbo C 1.5.  Am I the first person to 
> report a bug in Turbo C 1.5?  

No, since what you have observed is not a bug, but a *very* 
intended feature put in by Borland in version 1.5.  For more 
details, edit the README file that comes in disk #1 of your 
Turbo-C 1.5 distribution and scan for the string "memcpy", the 
information is in the errata section of the file.

> The Turbo C 1.0 memcpy() detects if the source and destination 
> overlap and switches the direction of the copying.  Borland 
> must have decided that the memcpy() routine should not be so 
> smart.  

Borland had changed memcpy() in order to make its behaviour 
comply with the ANSI C draft standard.  

> I have worked around this bug by extracting the old version out 
> of the old library.  

The above README file pointed out that the library function 
memmove() will handle overlapping region properly.

...Sam
-- 
Samuel Lam   {ihnp4!alberta,watmath,uw-beaver}!ubc-vision!van-bc!sklpc!skl