[comp.lang.c] bcopy and bzero on AT&T sysV

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