Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 (Tek) 9/26/83; site tekchips.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!cbosgd!ihnp4!houxm!houxz!vax135!cornell!uw-beaver!tektronix!tekchips!terryl
From: terryl@tekchips.UUCP (Terry Laskodi)
Newsgroups: net.bugs.4bsd
Subject: Re: Bug in 4.2 tip
Message-ID: <910@tekchips.UUCP>
Date: Tue, 3-Jul-84 14:04:59 EDT
Article-I.D.: tekchips.910
Posted: Tue Jul  3 14:04:59 1984
Date-Received: Thu, 5-Jul-84 00:16:09 EDT
References: <1007@linus.UUCP>
Organization: Tektronix, Beaverton OR
Lines: 50


     Another bug in tip(actually two bugs).

     1) In uucplock.c, in the routine ulockf(), there is a static array declared
char tempfile[NAMESIZE]. Now up above at the beginning of the file, NAMESIZE
is declared to be 15. Well, back in ulockf(), an sprintf() is done into
tempfile with the string "/usr/spool/uucp/LTMP.%d", pid. Guess what folks:
that's more than 15 characters!!!! On my machine, it just so happened that
the variable Nlocks came after tempfile, so when I was trying to close the
connection, Nlocks had a bogus value in it. Oh, by the way, I looked very
briefly, and the uucp code looks like it has the same problem. The fix??
Change NAMESIZE to something more reasonable, like 32.

     2) The above bug was reasonably blatant, but just an oversight. The next
bug is actually a questionable design flaw: There is a structure array that
holds the state of certain variables of the connection, most notably the state
of the ESC character (that funny character you type, plus another magic char-
acter to exit tip). Well, this structure is declared as

	struct	{
	..........			/* other un-interesting info */
		char *v_value;		/* casted to a union later */
	}

     Now the v_value variable can hold different information, depending on
what it is used for. It can hold a real character pointer, it can hold a
boolean value, and it can hold AN ACTUAL CHARACTER(emphasis mine). Now the
problem with it holding an actual character is that the structure is
initialized with a character pointer. And as the comment says, to reference
it as an actual character, it is casted to a character in a really obnoxious
way. The whole point is that this may work fine for a VAX or PDP where the
byte address of the character pointer is the low byte of the pointer, but on
a 68000-class processor, the byte address of the pointer is the high byte of
the pointer, so when the thing is coerced into a character, you pick up the
high byte which just happens to be 0. Kind of makes it hard to exit tip.
The fix?? In tip.h, approximately line 110 (look for the typedef union named
zzhack; boy did they name it right!!), change the line

		char zz_character;

to
		int zz_character;

or whatever size pointers are on your machine(for people who still have ints
as 2 bytes on a 68000-class processor).


				Terry Laskodi
				     of
				Tektronix