how to completely get rid of bcopy, bzero, bcmp? 
Author Message
 how to completely get rid of bcopy, bzero, bcmp?

I'm not much of a System V user, and I've always been lazy and fooled
with compatibility libs on most SVR[34] machines (I know I know, for
shame) to get bzero, bcopy and bcmp functionality.  Anyway, now I have
to build BSD telnetd for a Sequent running DYNIX/ptx 2.1.0 and lo, it's
just SVR3(?) no compatibility anything.  So anyway, for example, we
have a bcopy in slc.c:

                /*
                 * save this slc buffer if it is the first, otherwise dump
                 * it.
                 */
                if (def_slcbuf == (unsigned char *)0) {
                        def_slclen = len;
                        def_slcbuf = (unsigned char *)malloc((unsigned)len);
                        if (def_slcbuf == (unsigned char *)0)
                                return;  /* too bad */
                        bcopy(ptr, def_slcbuf, len);
                }

What should that bcopy() look like to make this SVR3 system happy?

Is there a "right" way to implement bcopy() etc on this system so I could
generate my own compatibility library and not bother with altering the
code every time?

Working with gcc 2.6.2 if it matters.

--
Paul Southworth
CICNet Systems Support



Tue, 20 May 1997 00:17:32 GMT  
 how to completely get rid of bcopy, bzero, bcmp?

Quote:

>                                 return;  /* too bad */
>                         bcopy(ptr, def_slcbuf, len);
>                 }
> What should that bcopy() look like to make this SVR3 system happy?
> Is there a "right" way to implement bcopy() etc on this system so I could
> generate my own compatibility library and not bother with altering the
> code every time?

#define bcopy(a,b,n)    memcpy((b),(a),(n))

--
Karl H. Brose
Greater Detroit Free-Net



Tue, 20 May 1997 17:08:52 GMT  
 how to completely get rid of bcopy, bzero, bcmp?

Quote:


>> Is there a "right" way to implement bcopy() etc on this system so I could
>> generate my own compatibility library and not bother with altering the
>> code every time?

> #define bcopy(a,b,n)       memcpy((b),(a),(n))

Safer would be

        #define bcopy(a,b,n) memmove((b),(a),(n))

, since later versions of BSD bcopy() allowed overlap, and many
programs are likely to rely on it.

(I would probably write the macro as

        #define bcopy(src, dest, n) memmove(dest, src, n)

to make the deliberate argument swap self-documenting.)

As an aside to the original poster: I don't know what code you're
having to "alter every time," but I would strongly recommend
changing the source code once and for all to use the ANSI
Standard mem* routines directly.  Most environments should
support them by now; on those few that don't, you could use a
header file or auxiliary library to implement them (perhaps in
terms of bcopy et al).

                                        Steve Summit



Wed, 21 May 1997 01:36:34 GMT  
 how to completely get rid of bcopy, bzero, bcmp?

Quote:


>>                                 return;  /* too bad */
>>                         bcopy(ptr, def_slcbuf, len);
>>                 }

>> What should that bcopy() look like to make this SVR3 system happy?

>> Is there a "right" way to implement bcopy() etc on this system so I could
>> generate my own compatibility library and not bother with altering the
>> code every time?

>#define bcopy(a,b,n)        memcpy((b),(a),(n))

this is not entirely correct. bcopy == memmove since it can handle
overlapping regions; memcpy does not.

christos



Wed, 21 May 1997 00:03:39 GMT  
 how to completely get rid of bcopy, bzero, bcmp?

Quote:


>>> Is there a "right" way to implement bcopy() etc on this system so I could
>>> generate my own compatibility library and not bother with altering the
>>> code every time?
[...]
>As an aside to the original poster: I don't know what code you're
>having to "alter every time," but I would strongly recommend
>changing the source code once and for all to use the ANSI
>Standard mem* routines directly.

I would tend to agree, however I'm not maintaining the code -- the point
is that I just wanted to make a compatibility header or library to
link in.  As it turns out, making a compatibility header is a pretty
easy way to do it.  Perhaps one of the NetBSD or 4.4BSD maintainers can
speak to this point.  It may just be legacy and spending time on more
pressing things.

The application in question was telnetd, NetBSD-current sources.

Quote:
>  Most environments should
>support them by now; on those few that don't, you could use a
>header file or auxiliary library to implement them (perhaps in
>terms of bcopy et al).

I got many useful responses, including a care package from Chris Torek
known as the comp.lang.c FAQ.  Funny, it seems to have your name on it ;)
You might consider adding a slightly more verbose explanation on easy
substitution of the mem* commands and strchr, etc if you think it wouldn't
take too much of the challenge out of it... (section 12.12)

Dimitri Papadopoulos Orfanos, Steve Davis, Garrett Wollman, Chuck Cranor
Faried Nawaz, and Nathaniel Ingersol all gave basically the same advice
as you mentioned w.r.t. working around bcopy, etc.  Some suggested using
memcpy, but I did end up using memmove since it appeared safer and more
portable.

I ended up using variants on this for most of the other Berkeley tools
I needed, as well as traceroute (which is still broken for other reasons).

+ #ifdef _SEQUENT_
+ #include <string.h>
+ #define index(s, c) strchr(s, c)
+ #define bcopy(s1, s2, len) ((void) memmove((s2), (s1), (len)))
+ #define bcmp(s1, s2, len) memcmp((s2), (s1), (len))
+ #define bzero(sp, len) ((void) memset((sp), 0, (len)))
+ #define gettimeofday(a,b) get_process_stats(a,getpid(),0,0)
+ #endif

The gettimeofday() kluge is a Sequent-ism (and is also needed for porting nvi
and emacs).  Jan Simon-Pendry also suggested using a wrapper for
getclock(2) to the same end, but this was easier.  (I hope it works right...)

By the way, GCC definitely vanished a number of the parse errors I got
out of the Sequent compiler.  Highly recommended as a first step before
starting porting jobs under Dynix/ptx 2.1.  People may need to use the
"-Xo" flag in the stage1 build, or do ALLOCA=alloca.o in the Makefile.

Back to the grinder...

--
Paul Southworth
CICNet Systems Support



Wed, 21 May 1997 10:27:18 GMT  
 how to completely get rid of bcopy, bzero, bcmp?

See memcpy, memset, memcmp.

--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Free your mind and your machine -- NetBSD free un*x for PC/Mac/Amiga/etc.
     Working NetBSD ports: 386+PC, Mac, Amiga, HP300, Sun3, Sun4c, PC532
               In progress: DEC pmax (MIPS R2k/3k), VAX, Sun4m
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -



Wed, 21 May 1997 11:37:54 GMT  
 how to completely get rid of bcopy, bzero, bcmp?
: I'm not much of a System V user, and I've always been lazy and fooled
: with compatibility libs on most SVR[34] machines (I know I know, for
: shame) to get bzero, bcopy and bcmp functionality.  Anyway, now I have
: to build BSD telnetd for a Sequent running DYNIX/ptx 2.1.0 and lo, it's
: just SVR3(?) no compatibility anything.  So anyway, for example, we
: have a bcopy in slc.c:

:                 /*
:                  * save this slc buffer if it is the first, otherwise dump
:                  * it.
:                  */
:                 if (def_slcbuf == (unsigned char *)0) {
:                         def_slclen = len;
:                         def_slcbuf = (unsigned char *)malloc((unsigned)len);
:                         if (def_slcbuf == (unsigned char *)0)
:                                 return;  /* too bad */
:                         bcopy(ptr, def_slcbuf, len);

        Why do u want rid it?
        At any case u can do it with
        # define bcopy (x, y, z) memcopy (y, x, z)

:                 }

: What should that bcopy() look like to make this SVR3 system happy?

: Is there a "right" way to implement bcopy() etc on this system so I could
: generate my own compatibility library and not bother with altering the
: code every time?

: Working with gcc 2.6.2 if it matters.

: --
: Paul Southworth
: CICNet Systems Support

--

                With best wishes -- Alex.



Sun, 25 May 1997 00:08:30 GMT  
 how to completely get rid of bcopy, bzero, bcmp?

Quote:

>:
>:                         bcopy(ptr, def_slcbuf, len);

>    Why do u want rid it?
>    At any case u can do it with
>    # define bcopy (x, y, z) memcopy (y, x, z)

Bad advice. This defines bcopy as ``(x, y, z) memcopy (y, x, z)''.
Not particularly useful.

As others have already pointed out, the correct macro is:

#define bcopy(x, y, z) memmove(y, x, z)

Dan
--
Dan Pop                       | The only reason God was able to make the
CERN, CN Division             | world in 7 days was he didn't have to remain

Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland



Tue, 27 May 1997 05:20:46 GMT  
 how to completely get rid of bcopy, bzero, bcmp?


: See memcpy, memset, memcmp.

The problem with memcpy is that it doesn't check for overlapping
regions.  where, as I understand it (coming from a SunOS/BSD 4.3
world), bcopy will handle overlaps correctly. From the memcpy(2)
manpage:
        memcpy(void *s1, const void *s2, size_t n);
        [...]
        If the source and destination areas overlap such that s2 <
        s1<s2 + n, the behavior is undefined.
        [...]
        ..if the source and destination areas overlap...use _rmemcpy [I
        think a machine-specific call?]

Also, the source and destination args to b*() are the reverse of mem*().

-ed

[sorry for multiple followup groups...]
: --
: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

:   Free your mind and your machine -- NetBSD free un*x for PC/Mac/Amiga/etc.
:      Working NetBSD ports: 386+PC, Mac, Amiga, HP300, Sun3, Sun4c, PC532
:                In progress: DEC pmax (MIPS R2k/3k), VAX, Sun4m
: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

--
---
        "You can't let go and you can't hold on,
         You can't go back and you can't stand still"
+---------------------------------+--------------------------------------+
! Edward Griebel                  ! Trading Systems Group                !

+---------------------------------+--------------------------------------+



Mon, 26 May 1997 05:14:30 GMT  
 how to completely get rid of bcopy, bzero, bcmp?

#ifdef HAVE_MEMMOVE
# define bcopy(a,b,c) memmove((b),(a),(c))
#else /* makes bcopy possibly not handle overlapping arguments */
# define bcopy(a,b,c) memcpy((b),(a),(c))
#endif

#define bzero(a,b) memset((a), 0, (b))
#define bcmp memcmp

is the right way to `fix' the bsd b* functions to work with system v.

.mrg.

--
matthew green      consultant    /\    the fulcrum consulting group

voice: +61 3 621 2100                  melbourne vic 3000
  fax: +61 3 621 2724                  australia                 /\



Mon, 09 Jun 1997 09:48:35 GMT  
 how to completely get rid of bcopy, bzero, bcmp?
: #ifdef HAVE_MEMMOVE
: # define bcopy(a,b,c) memmove((b),(a),(c))
[etc...]

Seems like the wrong way around to me.  There is a standard and it
specifies mem* so why not define them the other way round and use
the standard functions in your code?

#ifndef HAVE_MEMMOVE
#define memmove(a, b, c) bcopy((b), (a), (c))
[etc...]

Of course memset is a bit tricky to implement as a macro but it's
such a simple function to write that it isn't such a hardship.
At least bcopy() handles the overlap correctly.

--

Planix, Inc., Toronto, Canada       |   sheep voting on what's for dinner.
+1 416 424 2871  (DoD#0082) (eNTP)  |
      -- Info on Planix can be found at html://www.planix.com --



Tue, 10 Jun 1997 13:24:59 GMT  
 how to completely get rid of bcopy, bzero, bcmp?


: : #ifdef HAVE_MEMMOVE
: : # define bcopy(a,b,c) memmove((b),(a),(c))
: [etc...]
[ ... ]

I just use the libiberty.a library from FSF.
It's in the libg++ distribution, so at compile time you just say:

(g)cc -o prog prog.c -liberty

And it does indeed liberate you from all the bsd / sysv hassles.

--
 +-----------------------------------------------------------------------+
 | NAME   Christopher Sawtell                                            |
 | SNAIL  215 Ollivier's Road, Linwood, Christchurch, 8001. New Zealand. |

 | Learn C programming by e-mail. Get the lessons from:-                 |
 |   `svr-ftp.eng.cam.ac.uk:misc/sawtell_C.shar' Then write for details. |
 +-----------------------------------------------------------------------+



Thu, 12 Jun 1997 17:00:29 GMT  
 how to completely get rid of bcopy, bzero, bcmp?


   : #ifdef HAVE_MEMMOVE
   : # define bcopy(a,b,c) memmove((b),(a),(c))
   [etc...]

   Seems like the wrong way around to me.  There is a standard and it
   specifies mem* so why not define them the other way round and use
   the standard functions in your code?

   #ifndef HAVE_MEMMOVE
   #define memmove(a, b, c) bcopy((b), (a), (c))
   [etc...]

   Of course memset is a bit tricky to implement as a macro but it's
   such a simple function to write that it isn't such a hardship.
   At least bcopy() handles the overlap correctly.

which standard?  i shall not get in to this .. ;-)

the original post asked how to "get rid of" the b* functions,
not how to write portable code, etc.  i assume that they were
trying to port some (old) code to some system v like system
that didn't have the b* functions.

.mrg.

--
matthew green      consultant    /\    the fulcrum consulting group

voice: +61 3 621 2100                  melbourne vic 3000
  fax: +61 3 621 2724                  australia                 /\



Mon, 16 Jun 1997 08:11:09 GMT  
 
 [ 26 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Bcopy, bzero and bcmp on a not-Berkeley machine

2. Equivalent to BSD bzero, bcopy, bcmp

3. memcpy != bcopy (Was Re: bcopy() bzero())

4. bcopy and bzero on AT&T sysV

5. Bzero & bcopy warning with -ansi Cflag?

6. Getting rid of the web browser's toolbar

7. getting rid of C++ classes

8. getting rid of the DOS window in console application

9. Getting rid of leading whitesapce

10. Getting rid of the \n

11. Getting rid of the Carriage return

12. Getting rid of global

 

 
Powered by phpBB® Forum Software