rac@sherpa.UUCP (Roger A. Cornelius) (03/18/89)
Is there a routine in the system V library analogous to BSD's bcopy().
If not, can someone describe what bcopy() does ? I'm running SCO Xenix
if it matters.
Thanks,
Roger
--
Roger Cornelius rac@sherpa
uunet!sherpa!racsamlb@pioneer.arc.nasa.gov (Sam Bassett RCD) (03/19/89)
FTFM: bcopy( b1, b2, length ) char *b1, *b2; int length bcopy copies a string of bytes (treating \0 and everything else as just another byte from b1 to b2, for 'length' number of bytes. Sam'l Bassett, Sterling Software @ NASA Ames Research Center, Moffett Field CA 94035 Work: (415) 694-4792; Home: (415) 454-7282 samlb%well@lll-crg.ARPA samlb@pioneer.arc.nasa.gov <Standard Disclaimer> := 'Sterling doesn't _have_ opinions -- much less NASA!'
gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/19/89)
In article <114@sherpa.UUCP> rac@sherpa.UUCP (Roger A. Cornelius) writes: >Is there a routine in the system V library analogous to BSD's bcopy(). memcpy() is analogous but its arguments are in a different order. memcpy() is decribed under MEMORY(3C) in most System V PRMs. bcopy() is described under BSTRING(3) in the 4BSD PRM. In case you don;t have BSD documentation (why not?), just swap the first two arguments and change the name from bcopy to memcpy. Be sure to include <memory.h> to get memcpy()'s type declared correctly.
dave@pmafire.UUCP (Dave Remien) (03/20/89)
In article <114@sherpa.UUCP> rac@sherpa.UUCP (Roger A. Cornelius) writes: >Is there a routine in the system V library analogous to BSD's bcopy(). >If not, can someone describe what bcopy() does ? I'm running SCO Xenix >if it matters. > Being fundamentally in favor of making life easier, I have a file that I include in all BSD source at the top, which contains: #define bcopy(s,d,n) memcpy((d),(s),(n)) #define bcmp(s1,s2,n) memcmp((s1),(s2),(n)) #define bzero(s,n) memset((s),0,(n)) Works for me......... (I work almost exclusively in Sys V). >Thanks, >Roger >-- >Roger Cornelius rac@sherpa > uunet!sherpa!rac -- Dave Remien - WINCO Computer Engineering Group (only somewhat confused, now) Work - 208-526-3523 Home - 208-524-1906 UUCP Path: ...!bigtex!pmafire!dave "How can you be in two places at once, when you're not anywhere at all..."
chris@mimsy.UUCP (Chris Torek) (03/20/89)
>In article <114@sherpa.UUCP> rac@sherpa.UUCP (Roger A. Cornelius) asks: >>Is there a routine in the system V library analogous to BSD's bcopy(). In article <604@pmafire.UUCP> dave@pmafire.UUCP (Dave Remien) replies (and in other articles, others write): >Being fundamentally in favor of making life easier, I have a file that I >include in all BSD source at the top, which contains: > >#define bcopy(s,d,n) memcpy((d),(s),(n)) Beware: bcopy() is more like memmove() than memcpy(). This is not well documented, and is sometimes even false (e.g., for 4.2BSD with n > 65535 and s < d < s + n; for 4.2BSD-derived systems such as SunOS, I cannot even guess), but using memmove is safer. To put it another way: #define bcopy(s, d, n) memmove(d, s, n) will always work, while #define memmove(d, s, n) bcopy(s, d, n) may not. (The latter does work in 4.3BSD and 4.3BSD-tahoe.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/20/89)
In article <16451@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: > #define bcopy(s, d, n) memmove(d, s, n) >will always work, ... Except of course on systems that don't HAVE memmove(), like practically every commercial version of UNIX out there..
carroll@s.cs.uiuc.edu (03/21/89)
Out of curriosity, why in the world does bcopy have the source and destination
backwards from everything else? Just to confuse people trying to learn how
to use it?
Alan M. Carroll "And then you say,
carroll@s.cs.uiuc.edu We have the Moon, so now the Stars..." - YES
CS Grad / U of Ill @ Urbana ...{ucbvax,pur-ee,convex}!s.cs.uiuc.edu!carrollrac@sherpa.UUCP (Roger A. Cornelius) (03/21/89)
From article <9876@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn ): > In article <114@sherpa.UUCP> rac@sherpa.UUCP (Roger A. Cornelius) writes: >>Is there a routine in the system V library analogous to BSD's bcopy(). > > memcpy() is analogous but its arguments are in a different order. > memcpy() is decribed under MEMORY(3C) in most System V PRMs. > bcopy() is described under BSTRING(3) in the 4BSD PRM. > In case you don;t have BSD documentation (why not?), I don't have access to a BSD machine. I'm just trying to compile the BSD indent program, which has a call to bcopy(). > just swap the first two arguments and change the name from bcopy to memcpy. > Be sure to include <memory.h> to get memcpy()'s type declared > correctly. Thanks. Other replies just said to use memcpy. They didn't mention the args were reversed. Thanks to everyone else who replied also. Roger -- Roger Cornelius rac@sherpa uunet!sherpa!rac
kucharsk@uts.amdahl.com (William Kucharski) (03/21/89)
I just thought I'd add my $.02 to the SYSV bcopy traffic.
Using memcpy(3) will work in most cases on most machines.
However, a problem may occur when doing an overlapping copy:
From the SYSV man page CAVEATS:
"Character movement is performed differently in different implementations.
Thus overlapping moves may yield suprises."
The BSD (or at least SunOS 4.0) man page says of bcopy:
"Overlapping strings are handled correctly."
Just a little caveat...
--
William Kucharski
ARPA: kucharsk@uts.amdahl.com
UUCP: ...!{ames,decwrl,sun,uunet}!amdahl!kucharsk
Disclaimer: The opinions expressed above are my own, and may not agree with
those of any other sentient being, not to mention those of my
employer. So there.guy@auspex.UUCP (Guy Harris) (03/22/89)
>Is there a routine in the system V library analogous to BSD's bcopy().
"memcpy". The differences are:
1) the first and second arguments are reversed:
bcopy(from, to, count);
becomes
memcpy(to, from, count);
2) "memcpy" makes no guarantees that it'll work right if "from"
and "to" overlap; I don't have the 4.3-tahoe manual page
handy to see whether it guarantees that it'll work, but I
think most implementations do guarantee that, and some code
relies on it working. (The SunOS "bcopy" manual page says
that "Overlapping strings are handled correctly.")gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/22/89)
In article <216000009@s.cs.uiuc.edu> carroll@s.cs.uiuc.edu writes: >Out of curriosity, why in the world does bcopy have the source and destination >backwards from everything else? There are people who think that "copy FROM TO" is a more natural order. Presumably the fellow who wrote the first bcopy() thought so.
chris@mimsy.UUCP (Chris Torek) (03/22/89)
In article <9901@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: >There are people who think that "copy FROM TO" is a more natural order. >Presumably the fellow who wrote the first bcopy() thought so. ... along with the fellow who wrote /bin/cp. In actuality, it is strcpy() that is `backwards', supposedly done that way to make strcpy(dst, "foo"); `feel' more like the assignment dst = "foo"; found in languages with second-or-first-class arrays. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
ndjc@ccicpg.UUCP (Nick Crossley) (03/24/89)
One other point which no one else seems to have raised yet: the return value. memcpy, like strcpy, returns its first argument as a return value. No man page for bcopy that I have seen mentions a return value, so this is not guaranteed. So, as earlier posters have mentioned, bcopy can usually be replaced by memcpy or memmove, but the reverse is probably only true if the return value of memcpy is not used. -- <<< standard disclaimers >>> Nick Crossley, CCI, 9801 Muirlands, Irvine, CA 92718-2521, USA. (714) 458-7282 uunet!ccicpg!nick / nick@ccicpg.UUCP
guy@auspex.UUCP (Guy Harris) (03/26/89)
>One other point which no one else seems to have raised yet: the return >value. I think the reason nobody raised this is that the return value of "memcpy" is, in most cases, singularly useless; if I'd wanted the value of the first argument to "memcpy", I would have used it directly. I cannot remember *ever* having used either the return value of "memcpy" *or* the return value of "strcpy" in any code I've written.