Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!rutgers!rochester!lubkin
From: lubkin@cs.rochester.edu (Saul Lubkin)
Newsgroups: comp.unix.sysv386
Subject: pcomm, memcpy and bcopy
Message-ID: <1990Oct7.181015.16290@cs.rochester.edu>
Date: 7 Oct 90 18:10:15 GMT
Reply-To: lubkin@cs.rochester.edu (Saul Lubkin)
Organization: U of Rochester, CS Dept, Rochester, NY
Lines: 46

I've noticed that there have been some postings about pcomm, in which people
had problems with it.

I should note that I compiled pcomm, with the standard System V C compiler
that comes with ISC V/386 2.0.2, and that I've had absolutely no problems with
it.  Quite the contrary; I very much like the program.  I use it instead of
cu (or Procomm running under DOS under VP/ix).

I like pcomm's script language: namely, it's simply the Unix shell!  So, you
don't have to learn a new language.  I'm writing this note now, logged onto my
account in the Computer Science Dept. at the Univ. of Rochester, from my
home ISC Unix computer, connected via a Hayes compatible 2400 Baud modem, using
pcomm.  I have no trouble running vi remotely, this way (as I am now).

I noticed postings to the net, describing strange bugs in pcomm, that seem to
suggest memory management problems.  I think I might know the source of these
problems (anyway, here's a guess:)

When you compile pcomm, you're supposed to edit a setup file, which sets certain
parameters for your system.  One of these, is to indicate whether to use "bcopy"(a standard Berkeley Unix C function, for copying a block of memory), or
"memcpy" (essentially the same thing, on System V systems).  There is also a
third option, that indicates that you don't have either (or that there's 
something wrong with the one that you have).

Although ISC System V/386, and other flavors of V/386, have "memcpy" (but
usually not "bcopy"), I chose the third alternative; namely, that I don't
have either.  The reason:  pcomm's documentation indicates that this copying
function is supposed to work correctly, EVEN IF COPYING TO A PARTIALLY
OVERLAPPING REGION.  Berkeley "bcopy" is guaranteed to work correctly, in
such cases -- but, on reading the AT&T manuals about "memcpy", the manuals
specifically warn that (not quoted exactly) "some implementations of Sys V
memcpy" do not work correctly under those circumstances.

So, I told "pcomm" that I DIDN'T have a susitable "memcpy" or "bcopy" (since
in fact I probably don't).  "pcomm" substituted it's own (trivial to program)
routine for the missing "bcopy" -- and the resultiong "pcomm" has worked
perfectly.

Just thought that I would share this with you netlanders.

My thanks to the author of pcomm, for an excellent program.


						Saul Lubkin

						lubkin@rochester.cs.edu