Xref: utzoo comp.std.c:552 comp.windows.x:6627
Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.std.c,comp.windows.x
Subject: Re: bcopy
Message-ID: <9123@smoke.BRL.MIL>
Date: 9 Dec 88 22:52:42 GMT
References: <9095@smoke.BRL.MIL> <9167@ihlpb.ATT.COM> <1356@astroatc.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 30

In article <1356@astroatc.UUCP> johnw@astroatc.UUCP (John F. Wardale) writes:
>What does the following mean?  [What should it do?]
>			bcopy (&a[0], &a[1], 19);
>			bcopy (&a[1], &a[0], 19);
>The vax-BSD 4.3 "man bcopy" doesn't mention this.
> the SUN "man bcopy" says:
>"Overlapping strings are handled correctly."

One has no way to guess whether or not overlapping arrays are
handled "correctly" unless, as Sun did, the vendor ensures this
attribute.

>Emacs (a highly ported program) *ASSUMES* (needs/uses) this
>overlaping semantic.

It sounds like it relies on an undocumented and therefore
unreliable feature of some implementations.  Since bcopy()
normally would be implemented as highly-tuned assembly code,
rather than in portable C, one is entirely at the mercy of
the BSD-flavor C library implementer.

ANSI C recognizes the need for a faster, non-checking function
and an overlap-supporting function, and doesn't have bcopy()
at all (neither does UNIX System V).  So, unless EMACS source
comes with its own implementation anyway, it is far from
portable in this respect.

By the way, I have a portable overlap-supporting block-move
implementation in C in case anyone needs it.  Perhaps if the
GNU project doesn't already have such a beast they could pick
up mine.