[comp.unix.microport] running "pcomm" on Sys V/AT

john@wa3wbu.UUCP (John Gayman) (09/16/88)

    Has anyone been successfull in compiling and running the recently
posted "pcomm" communications software under Sys V/AT ?  I have no
trouble getting it to compile without errors but it always "core dumps"
when I try anything to use the modem or exit. I can go from screen to
screen configuring the modem setup and terminal specs, editing the
dialing directory. All is fine till I exit the program and then it
core dumps with a memory fault. I can even execute the program and
immediately exit and it will core dump. Can anyone offer any suggestions ?
Would like to compare notes with someone who has it running. Thanks!!


						John


-- 
John Gayman, WA3WBU              |           UUCP: uunet!wa3wbu!john
1869 Valley Rd.                  |           ARPA: john@wa3wbu.uu.net 
Marysville, PA 17053             |           Packet: WA3WBU @ AK3P 

scotty@l5comp.UUCP (Scott Turner) (09/17/88)

Deep in the heart of ports.c of pcomm you will find a if statement that
checks *str != NULL || str != NULL. This needs to be reversed so that it
checks if str is NULL before it checks to see if what str points at is
NULL.

I've sent the author an E-Mail about this.

Scott Turner
scotty@l5comp -or- uunet!l5comp!scotty

john@wa3wbu.UUCP (John Gayman) (09/18/88)

In article <424@l5comp.UUCP>, scotty@l5comp.UUCP (Scott Turner) writes:
> Deep in the heart of ports.c of pcomm you will find a if statement that
> checks *str != NULL || str != NULL. This needs to be reversed so that it

       There is a file called port.c but not ports.c. And I searched
through all the occurances of "str" and there is no line like you
mention above. Can you clarify where it is located ? Thanks !


					John



-- 
John Gayman, WA3WBU              |           UUCP: uunet!wa3wbu!john
1869 Valley Rd.                  |           ARPA: john@wa3wbu.uu.net 
Marysville, PA 17053             |           Packet: WA3WBU @ AK3P 

tkevans@fallst.UUCP (Tim Evans) (09/18/88)

In article <633@wa3wbu.UUCP>, john@wa3wbu.UUCP (John Gayman) writes:
> 
>     Has anyone been successfull in compiling and running the recently
> posted "pcomm" communications software under Sys V/AT ?

I had the same experience as John, but when I applied Emmet Gray's
first two official patches, the core dump problem went away.  (Some
others remain, though, which I will detail as I can.)  NOTE:  pcomm
must be compiled on SysV/AT using 'large' memory model.
-- 
UUCP:  ...!{rutgers|ames|uunet}!mimsy!aplcen!wb3ffv!fallst!tkevans
OTHER: ...!attmail!fallst!tkevans
Tim Evans  2201 Brookhaven Court, Fallston, MD  21047   (301) 965-3286

scotty@l5comp.UUCP (Scott Turner) (09/19/88)

					/* remove the lock */
/*	if (*lock_path != NULL && lock_path != NULL) { */
	if ((lock_path != NULL) && (*lock_path != NULL)) {
		if (unlink(lock_path)) {
			sprintf(buf, "'%s'", lock_path);
			error_win(0, "Can't remove the lock file", buf);
		}
		free_ptr(lock_path);
		lock_path = null_ptr;
	}
					/* turn the getty back on? */

Scott Turner
scotty@l5comp -or- uunet!l5comp!scotty

suhans@let.vu.nl (suhans) (09/19/88)

In article <635@wa3wbu.UUCP>, john@wa3wbu.UUCP (John Gayman) writes:
> In article <424@l5comp.UUCP>, scotty@l5comp.UUCP (Scott Turner) writes:
> > Deep in the heart of ports.c of pcomm you will find a if statement that
> > checks *str != NULL || str != NULL. This needs to be reversed so that it
> 
>        There is a file called port.c but not ports.c. And I searched
> through all the occurances of "str" and there is no line like you
> mention above. Can you clarify where it is located ? Thanks !
> 
> 
You must not search for str or *str but you must search for NULL in
port.c and then change it to the above line. str is not the variable
the variable is lock_path. str just means a string but not the string.
I have changed it in curses.c to, but the names are different again.
So *str !=NULL || str != NULL must always be str != NULL || *str !=NULL
Just search for NULL in the file when you find *???? != NULL you
change it to ???? != NULL || *???? != NULL
I compiled it and it does work, the only problem is that the screen
layout doesn't work right, I don't know if the problem is my curses
or there is something wrong in the program.
But I can call other systems using pcomm


Organisation:	Free University, Faculty of Literature
                Amsterdam, the Netherlands      
Name:		Hans Varkevisser (system administrator) 
                hans@let.vu.nl  or let.vu.nl!hans (UUCP)

wnp@dcs.UUCP (Wolf N. Paul) (09/19/88)

In article <635@wa3wbu.UUCP> john@wa3wbu.UUCP (John Gayman) writes:
 >In article <424@l5comp.UUCP>, scotty@l5comp.UUCP (Scott Turner) writes:
 >> Deep in the heart of ports.c of pcomm you will find a if statement that
 >> checks *str != NULL || str != NULL. This needs to be reversed so that it
 >
 >       There is a file called port.c but not ports.c. And I searched
 >through all the occurances of "str" and there is no line like you
 >mention above. Can you clarify where it is located ? Thanks !

The line actually reads:

	if (*lock_path != NULL || lock_path != NULL) {

Scott thus used "str" as a generic name for a string, similar to the
way names are used in the "SYNOPSIS" portion of a typical UNIX manual
page. When the manual page says that "fopen()" is called as,
"fopen(file-name, type)", that doesn't mean that you always have to call
the first argument "file-name" and the second one "type".

Be a bit creative in interpreting USENET postings :-) ...
-- 
Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101
UUCP:     killer!dcs!wnp                 ESL: 62832882
DOMAIN:   dcs!wnp@killer.dallas.tx.us    TLX: 910-380-0585 EES PLANO UD

rfarris@serene.CTS.COM (Rick Farris) (09/20/88)

In article <427@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes:
>/*	if (*lock_path != NULL && lock_path != NULL) { */
>	if ((lock_path != NULL) && (*lock_path != NULL)) {
>
>Scott Turner

Wait a second.  Isn't there another problem here?  Doesn't this assume that
the size of a pointer, and the size of a char are the same?  Shouldn't this
really be:

	if ((lock_path != NULL) && (*lock_path != (char)NULL)) {

My compiler complains...
                      _______________________________
Rick Farris          |     rfarris@serene.cts.com    |   Voice  (619) 259-6793
POB M                |    ...!uunet!serene!rfarris   |   BBS          259-7757
Del Mar, CA 92014    |_______________________________|   serene.UUCP  259-3704

If carpenters built buildings the way most programmers write programs,
         the first woodpecker that came along would destroy civilization. . .

chad@anasaz.UUCP (Chad R. Larson) (09/20/88)

In article <633@wa3wbu.UUCP> john@wa3wbu.UUCP (John Gayman) writes:
>
>    Has anyone been successfull in compiling and running the recently
>posted "pcomm" communications software under Sys V/AT ?  I have no
>trouble getting it to compile without errors but it always "core dumps"
>when I try anything to use the modem or exit.

There was a simple bug in line 216 of file port.c that resulted in 
dereferencing a NULL pointer.  I e-mailed the fix to the author, I
guess I should have posted it too, but I thought a bunch of other
folks would.   The line should read:

  if (lock_path != NULL && *lock_path != NULL) {

The shipped code checks what lock_path points to *before* checking
it for NULL.

No Charge!	-crl
---------------
"I read the news today, oh boy!"  --John Lennon
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| DCF, Inc.               | UUCP: ...ncar!noao!nud!anasaz!dcfinc!chad   |
| 14623 North 49th Place  | Ma Bell: (602) 953-1392                     |
| Scottsdale, AZ 85254    | Loran: N-33deg37min20sec W-111deg58min26sec |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|         Disclaimer: These ARE the opinions of my employer!            |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

scotty@l5comp.UUCP (Scott Turner) (09/21/88)

In article <218@serene.CTS.COM> rfarris@serene.cts.com (Rick Farris) writes:
>	if ((lock_path != NULL) && (*lock_path != (char)NULL)) {
>
>Rick Farris          |     rfarris@serene.cts.com    |   Voice  (619) 259-6793

OK, ok, ok! The line should really read:
	if ((lock_path != NULL) && (*lock_path != '\0')) {

And for those REAL nit pickers out there, yes I put in extra ()'s. The compiler
will process the line with or without the extra ()'s, but it makes it easier
for me to parse the line at 03:00. :) No need to slosh the poor brain cells
to remember if && binds before != etc... I heartily recomend them to those
who are new to C.

On a different topic, I just received a mail message from a person here on
the net claiming that Microport refused to sell him an Update contract! (he
didn't say what version of unix he was trying to get a contract for)

What gives? Are they no longer available? If not, why not? Are hotline
contracts next if this is so?

Scott Turner
scotty@l5comp -or- uunet!l5comp!scotty

hood@osiris.cso.uiuc.edu (09/23/88)

Has no one heard of comp.sources.bugs?  There are three offical (and
one un-offical) patches to Pcomm v1.1 waiting there for you to download!

Emmet P. Gray				US Army, HQ III Corps & Fort Hood
...!uunet!uiucuxc!fthood!egray		Attn: AFZF-DE-ENV
					Directorate of Engineering & Housing
					Environmental Management Office
					Fort Hood, TX 76544-5057

jay@splut.UUCP (Jay Maynard) (09/24/88)

In article <42700003@osiris.cso.uiuc.edu> hood@osiris.cso.uiuc.edu writes:
>Has no one heard of comp.sources.bugs?  There are three offical (and
>one un-offical) patches to Pcomm v1.1 waiting there for you to download!

And, after those three official patches, it runs just fine, thank you.
I'm running HDB UUCP (the latest version from the BBS), and the
suggested configuration options work; I had to define WGETCH_BROKE,
too. Don't miss that one, as dialing doesn't work worth a flip if you
need it and don't have it set.
I also set it to setuid uucp, and made the program file mode 755.

-- 
Jay Maynard, EMT-P, K5ZC...>splut!< | Never ascribe to malice that which can
uucp:       uunet!nuchat!           | adequately be explained by stupidity.
   hoptoad!academ!uhnix1!splut!jay  +----------------------------------------
{killer,bellcore}!tness1!           | "Those are indeed tough bananas."