*BSD News Article 38818


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