kmeek@cti1.UUCP (Meek) (06/15/90)
I am trying to compile a C program that uses bcopy() and bzero() functions. The linker bombs because it doesn't know bcopy and bzero. I am compiling this on an AT&T 3B2/600G running System V 3.2.2 I assume the problem is that bcopy and bzero are bsd functions that are not supported in sysV. If this is the case is there a sysV function that I can substitute? If not, anyone have source for bcopy() and bzero() that would work on a 3B2 and is public domain ?? Thanks in advance for any suggestions. Kevin Meek Comprehensive Technologies Int'l Inc. 2121 Crystal Drive Suite #103 Arlington, VA 22202 uunet!cit1!kmeek OR cti1!kmeek@uunet.uu.net
cpcahil@virtech.uucp (Conor P. Cahill) (06/15/90)
In article <213@cti1.UUCP> kmeek@cti1.UUCP (Meek) writes: >I am trying to compile a C program that uses bcopy() and bzero() >functions. The linker bombs because it doesn't know bcopy and bzero. Use the following: #define bzero(ptr,cnt) memset(ptr,'\0',cnt) #define bcopy(src,dest,cnt) memcpy(dest,src,cnt) Note that memcpy is not guarranteed to handle overlapping moves, while bcopy is assumed to by some programs. I have used these #defines on lots of net code without any problems. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
karl@haddock.ima.isc.com (Karl Heuer) (06/15/90)
In article <1990Jun14.233837.22318@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >Note that memcpy is not guarranteed to handle overlapping moves, while >bcopy is assumed to by some programs. Despite the fact that bcopy is also not guaranteed to handle them (at least not in the 4.3BSD man page), and often doesn't. It's better to use the mem-functions directly rather than the b-functions, since the former are part of the ANSI Standard library, and since they allow you to specify whether you need the additional semantics of overlapping moves (memmove() vs. memcpy()). If you need memmove() and your implementation doesn't support the Standard library yet, the enclosed source may help. Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint --------cut here-------- #include <string.h> /* * Same as memcpy, but with guaranteed semantics on overlap. This algorithm * assumes trichotomy is valid even when the operands don't point into the * same array. */ void *memmove(void *adest, void *asrc, size_t n) { if (n != 0) { register char *dest = (char *)adest; register char *src = (char *)asrc; if (src > dest) { do *dest++ = *src++; while (--n != 0); } else if (src < dest) { src += n; dest += n; do *--dest = *--src; while (--n != 0); } } return (adest); }
cpcahil@virtech.uucp (Conor P. Cahill) (06/15/90)
In article <16891@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: >In article <1990Jun14.233837.22318@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >>Note that memcpy is not guarranteed to handle overlapping moves, while >>bcopy is assumed to by some programs. > >Despite the fact that bcopy is also not guaranteed to handle them (at least >not in the 4.3BSD man page), and often doesn't. > >It's better to use the mem-functions directly rather than the b-functions, >since the former are part of the ANSI Standard library, and since they allow This is true if you are developing code. However, if you are just porting code you normally don't want to make zillions of changes when they can be taken care of with a simple #define. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
joe@proto.COM (Joe Huffman) (06/16/90)
In article <16891@haddock.ima.isc.com>, karl@haddock.ima.isc.com (Karl Heuer) writes: > #include <string.h> > /* > * Same as memcpy, but with guaranteed semantics on overlap. This algorithm > * assumes trichotomy is valid even when the operands don't point into the > * same array. > */ > void *memmove(void *adest, void *asrc, size_t n) { > if (n != 0) { > register char *dest = (char *)adest; > register char *src = (char *)asrc; > if (src > dest) { > do *dest++ = *src++; while (--n != 0); > } else if (src < dest) { > src += n; > dest += n; > do *--dest = *--src; while (--n != 0); > } > } > return (adest); > } The comparisions 'if(src > dest)' and 'if(src < dest)' will only compare the offset with most (all?) C compilers for the 80x86. If you are moving memory contents between different segments then it is quite possible to have both conditions fail. This would result in no memory being moved with the algorithm as written. Also, when in real mode two pointers can point to the same memory location with different segment values. Hence 'if(src > dest)' could test true even the absolute value of src were less than dest. The way to write the function would be to normalized the pointers before doing the comparision, then just do one comparision. That is, don't do 'else if' just do 'else'. Unless you are concerned about being passed pointers to the same exact memory locations in which case you should do 'else if(src != dest)'. The '==' and '!=' comparisions do full comparisions on the pointers, not just the offset portion. You still must do the normalization however. This comparision of offset only for '>' and '<' 'feature' has bit me (and many others) more times than I care to admit. And it results in some extremely subtle bugs that disappear and reappear at odd times. -- joe@proto.com uunet!proto!joe FAX: 208-263-8772