Return to BSD News archive
Xref: sserve comp.unix.bsd:15430 comp.lang.c:86911 comp.unix.sys5.r3:2298 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!uwm.edu!cs.utexas.edu!swrinde!gatech!newsxfer.itd.umich.edu!news.cic.net!cedar.cic.net!not-for-mail From: pauls@cedar.cic.net (Paul Southworth) Newsgroups: comp.unix.bsd,comp.lang.c,comp.unix.sys5.r3 Subject: SUMMARY Re: how to completely get rid of bcopy, bzero, bcmp? Date: 2 Dec 1994 21:27:18 -0500 Organization: CICNet, Inc. Lines: 64 Message-ID: <3bol26$io2@cedar.cic.net> References: <3bksus$fg4@spruce.cic.net> <3bmo74$oan@detroit.freenet.org> <D07294.5MJ@eskimo.com> NNTP-Posting-Host: cedar.cic.net In article <D07294.5MJ@eskimo.com>, Steve Summit <scs@eskimo.com> wrote: >> Paul Southworth (pauls@locust.cic.net) wrote: >>> 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. > 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 pauls@cic.net