johnw@astroatc.UUCP (John F. Wardale) (12/09/88)
[Sorry it this isn't the "perfect" group for this, but y'all were
talking about index vs strchr so this can't be too far off.]
What does the following mean? [What should it do?]
char a[20];
/* first sample: */
bcopy (&a[0], &a[1], 19);
/* second sample: */
bcopy (&a[1], &a[0], 19);
BACKGROUND NOTES:
The vax-BSD 4.3 "man bcopy" doesn't mention this.
the SUN "man bcopy" says:
"Overlapping strings are handled correctly."
Emacs (a highly ported program) *ASSUMES* (needs/uses) this
overlaping semantic.
This is the libc bcopy, not the kernel version [that's one
VAX-instructon] or the kernel "ovbcopy"
--
John Wardale
... {seismo | harvard | rutgers | ames} ! {uwvax | cs.wisc.edu} ! astroatc!johnw
or astroatc!johnw@cs.wisc.edu
To err is human, to really foul up world news requires the net!jpn@genrad.com (John P. Nelson) (12/09/88)
>What does the following mean? [What should it do?]
[ Examples of the use of "bcopy" with overlapping regions deleted ]
Considering that "bcopy" is not part of the ANSI standard, bcopy's behavior
is not standardized. I would have to say that each vendor's implementation
of bcopy is free to handle overlapping strings or not, depending on their
preference. If the BSD 4.3 bcopy manual page doesn't explicitly say it
handles overlapping copies, then you can't count on it.
I would recommend the use of the the new ANSI standarized functions:
"memcpy", which is guaranteed to be fast, and "memmove" which is
guaranteed to work with overlapping regions.
john nelson
UUCP: {decvax,mit-eddie}!genrad!teddy!jpn
smail: jpn@teddy.genrad.comgwyn@smoke.BRL.MIL (Doug Gwyn ) (12/10/88)
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.
guy@auspex.UUCP (Guy Harris) (12/10/88)
>[Sorry it this isn't the "perfect" group for this, but y'all were > talking about index vs strchr so this can't be too far off.] [Except "bcopy" isn't part of any ANSI C draft, so it's definitely not a "C Standard" issue, it's more of a UNIX issue. (The ANSI C drafts specify "memcpy", and the S5 man page explicitly says that it's implementation-dependent - "overlapping moves may yield surprises".)] >What does the following mean? [What should it do?] It *appears* that the 4.3BSD implementation is intended not to yield surprises. The 4.3-tahoe documentation doesn't appear to make any such claim (although the C-language version also appears to be intended not to yield surprises). Keith? Chris? If being unsurprising is intended to be a defined characteristic of the interface, the man page should really state that, so that implementors don't screw up.