peter@radig.UUCP (Peter Radig) (09/25/89)
Is is possible to replace calls to `bcopy', `bzero' and `bcmp' by
the following macros:
#ifdef USG
#define bcmp(s1,s2,cnt) memcpy(s1,s2,cnt)
#define bcopy(fr,to,cnt) memcpy(to,fr,cnt)
#define bzero(addr,cnt) memset(addr,'\0',cnt)
#endif USG
or are there restrictions?
Is there a little c-program etc. which helps me to test the compatibility?
Thnx,
Peter
--
Peter Radig Voice: +49 69 746972
USENET: peter@radig.UUCP
or: uunet!unido!radig!peterkucharsk@uts.amdahl.com (William Kucharski) (09/26/89)
In article <1155@radig.UUCP> peter@radig.UUCP (Peter Radig) writes: >Is is possible to replace calls to `bcopy', `bzero' and `bcmp' by >the following macros: > > #ifdef USG > #define bcmp(s1,s2,cnt) memcpy(s1,s2,cnt) This should be memcmp(s1,s2,cnt) > #define bzero(addr,cnt) memset(addr,'\0',cnt) This should be fine. > #define bcopy(fr,to,cnt) memcpy(to,fr,cnt) Here's where you may have problems, depending upon the use in your program. The big difference between bcopy and memcpy is that bcopy is defined to handle copies of overlapping ranges of memory correctly while memcpy's behavior in the same situtation is implementation and/or architecture dependent. Hope this helps... -- =============================================================================== | ARPA: kucharsk@uts.amdahl.com | William Kucharski | | UUCP: ...!{ames,apple,sun,uunet}!amdahl!kucharsk | Amdahl Corporation | =============================================================================== | Saying: "It's a window system named 'X,' NOT a system named 'X Windows'" | =============================================================================== | Disclaimer: "The opinions expressed above may not agree with mine at any | | other moment in time, so they certainly can't be those of my | | employer." | ===============================================================================
meissner@tiktok.dg.com (Michael Meissner) (09/26/89)
In article <1155@radig.UUCP> peter@radig.UUCP (Peter Radig) writes: | Is is possible to replace calls to `bcopy', `bzero' and `bcmp' by | the following macros: | | #ifdef USG | #define bcmp(s1,s2,cnt) memcpy(s1,s2,cnt) | #define bcopy(fr,to,cnt) memcpy(to,fr,cnt) | #define bzero(addr,cnt) memset(addr,'\0',cnt) | #endif USG | | or are there restrictions? Some programs that use bcopy depend on it 'doing the right thing' when given pointers to overlapping regions. The memcpy routine has no such guarantee. If your system vendor has added the new ANSI C routine `memmove', you can replace bcopy with a call to memmove. I would suspect memmove is not yet in most libraries. You could just hope and pray, you never have overlapping strings (or inspect the code, or write your own). Our database people found an interesting quirk -- they were doing *lots* of block moves of overlapping regions, and found that the hardware character move (which could move in either direction) was *noticably* faster moving left to right rather than right to left. It was so much of a difference, that it was faster to move the bytes into an automatic array, and then move them again than. I've seen some implementations of bcopy, et. al, that do the same thing (ie, optimize the common case, and revert to single byte load/stores for the overlapping case). -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner If compiles were much Internet: meissner@dg-rtp.DG.COM faster, when would we Old Internet: meissner%dg-rtp.DG.COM@relay.cs.net have time for netnews?
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (09/26/89)
In article <13p902Mz5aZY01@amdahl.uts.amdahl.com>, kucharsk@uts.amdahl.com (William Kucharski) writes: | > #define bcopy(fr,to,cnt) memcpy(to,fr,cnt) | | Here's where you may have problems, depending upon the use in your program. | The big difference between bcopy and memcpy is that bcopy is defined to | handle copies of overlapping ranges of memory correctly while memcpy's | behavior in the same situtation is implementation and/or architecture | dependent. What you want here is memmove, not memcpy. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
diamond@csl.sony.co.jp (Norman Diamond) (09/27/89)
In article <1155@radig.UUCP> peter@radig.UUCP (Peter Radig) writes: > >Is is possible to replace calls to `bcopy', `bzero' and `bcmp' by > >the following macros: > > #define bcopy(fr,to,cnt) memcpy(to,fr,cnt) In article <13p902Mz5aZY01@amdahl.uts.amdahl.com> kucharsk@amdahl.uts.amdahl.com (William Kucharski) writes: > The big difference between bcopy and memcpy is that bcopy is defined to > handle copies of overlapping ranges of memory correctly while memcpy's > behavior in the same situtation is implementation and/or architecture > dependent. Where is it guaranteed that bcopy handles overlapping ranges correctly? It's not in the BSD 4.3 man page. >| Saying: "It's a window system named 'X,' NOT a system named 'X Windows'" | Ah, but what do you CALL the name? -- H. Dumpty (per L. Carroll). -- -- Norman Diamond, Sony Corporation (diamond@ws.sony.junet) The above opinions are inherited by your machine's init process (pid 1), after being disowned and orphaned. However, if you see this at Waterloo or Anterior, then their administrators must have approved of these opinions.
kaercher%isaak@isaak.uucp (Michael Kaercher) (09/27/89)
In article <1155@radig.UUCP> peter@radig.UUCP (Peter Radig) writes: >Is is possible to replace calls to `bcopy', `bzero' and `bcmp' by >the following macros: > > #ifdef USG > #define bcmp(s1,s2,cnt) memcpy(s1,s2,cnt) ^^^^^^ This should be memcmp! > #define bcopy(fr,to,cnt) memcpy(to,fr,cnt) > #define bzero(addr,cnt) memset(addr,'\0',cnt) > #endif USG There may be a big surprise when using these definitions! bcopy does handle overlapping memory areas correctly whereas memcpy is usually *not* implemented this way. In case you are porting to Microsoft C: there is a function in the runtime library called 'memmove' which does handle over- lapping regions properly. You can check out whether your definitions are proper with a little program similar to the following: main() { static char abc[] = "abcdefghi"; static char buffer[50]; strcpy (buffer, abc); bcopy (buffer, buffer + 1, sizeof(abc)); puts (buffer); strcpy (buffer, abc); bcopy (buffer + 1, buffer, sizeof(abc)); puts (buffer); } You should get: 'aabcd...' and 'bbcde...'. If the first line of output shows up as 'aaaaaa...', bcopy (or the program above(?)) is borken... BTW, i suppose that this feature in bcopy is due to the VAX MOVC3 instruction Hope this helps, Michael
chris@mimsy.UUCP (Chris Torek) (09/28/89)
In article <10884@riks.csl.sony.co.jp> diamond@csl.sony.co.jp (Norman Diamond) writes: >Where is it guaranteed that bcopy handles overlapping ranges correctly? >It's not in the BSD 4.3 man page. The guarantee was added somewhat late in the game. Incidentally, in the new C library, bcopy, memcpy, and memmove will all be identical. We would be happier with only one routine, but there is this standard thing. . . . -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
bostic@ucbvax.BERKELEY.EDU (Keith Bostic) (09/29/89)
> Where is it guaranteed that bcopy handles overlapping ranges correctly? > It's not in the BSD 4.3 man page. This was unfortunate, and has been fixed. The bcopy instruction was originally modeled after the VAX MOVC instruction, which is clearly documented to handle overlap. Besides, not handling overlap is stupid. --keith