Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!gatech!bloom-beacon!athena.mit.edu!scs
From: scs@athena.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: memcpy vs. memmove (was: Re: Explanation, please!)
Message-ID: <7039@bloom-beacon.MIT.EDU>
Date: 13 Sep 88 01:55:03 GMT
References: <8389@smoke.ARPA>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 21

In article <8389@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn) writes:
>Some implementations of bcopy() and memcpy() do guarantee
>proper handling of overlapping fields.  But not all do, so one cannot
>count on it if one's trying to write truly portable code.  ANSI C will
>specify a new function memmove() with this property guaranteed.

I'll probably be disgusted by the answer, but can someone explain
why two functions are needed instead of one?  Why not just add
the guarantee to memcpy?  In my experience, it's not hard to
implement the correct, bidirectional copy behavior.  Did someone
actually manage to convince the committee that there is an
architecture and/or implementer out there that is so badly broken
that the overlap test would significantly slow down programs
which did not need the guarantee?  Or is it a code size issue for
potential in-line implementations?  (I am aware that a correct
overlap test is not trivial for badly broken architectures such
as the segmented 80x86, but the correct test on those machines is
not really hard or slow, either.)

                                            Steve Summit
                                            scs@adam.pika.mit.edu