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!jb@CS.BROWN.EDU (12/09/88)
> char a[20]; > /* first sample: */ > bcopy (&a[0], &a[1], 19); > /* second sample: */ > bcopy (&a[1], &a[0], 19); Assuming the array initially contains "abcdefghijklmnopqrst", the first should yield "aabcdefghijklmnopqrs" while the second will result in "bcdefghijklmnopqrstt". This is what Sun means when they say that "overlapping strings are handled correctly." The second one should behave that way in all cases. The first might end up with the array containing 20 'a's if overlapping copies are done in a simple character at a time loop. To make this a bit more X related, I had to fix bcopy on the Encore Multimax to work around this problem. Jim
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.