Xref: utzoo comp.sys.att:2999 unix-pc.general:546
Path: utzoo!mnetor!uunet!ncc!alberta!teletron!andrew
From: andrew@teletron.UUCP (Andrew Scott)
Newsgroups: comp.sys.att,unix-pc.general
Subject: Re: 7300 uucp trouble with setgetty!
Message-ID: <250@teletron.UUCP>
Date: 11 Apr 88 17:38:55 GMT
References: <120@slbtoy.UUCP> <115@csanta.UUCP> <121@slbtoy.UUCP>
Organization: TeleTronic Communications Ltd., Edmonton, Alta.
Lines: 70
Keywords: getoff.sh - grrrr
Summary: setgetty is a badly written program, that's all

In article <121@slbtoy.UUCP>, slb@slbtoy.UUCP (Sanford L. Barr) writes:
> 
> The transfer works fine... I receive all the incoming news.  Then,
> when the machines are about to hangup, my machine spawns a "getoff.sh".
> "getoff.sh" is a shell script that calles "setgetty" which is supposed
> to take the getty off the modem line (why?  I don't know - it should be
> spawning a new one insead shouldn't it?).  Anyhow, the setgetty call hangs
> FOREVER - which causes the uucico process to wait around, which stops
> my news from being processed.
> 
> 	Does anyone know what's causing this?  Or am I going to have
> to try my hand at the AT&T hotline.

We have had problems with /usr/bin/setgetty ever since we became a uucp node
two years ago.  It really was a hassle when setgetty hung on a uucp call on
Friday night, and nobody caught it until Monday morning.  We would be two days
behind in news & mail.

Recently I wrote a disassembler that produced UNIX pc assembler source from a
COFF object file.  Before you ask, no I can't post it.  Besides, it's not very
polished right now.  I disassembled the object file for /usr/bin/setgetty and
reverse-compiled the .s file into a C source file.  Having looked at lots of
.s files to examine the compiler's output made it easier to identify what
C statements certain assembler sequences were derived from.

Anyway, the gist of this story is that the original code for setgetty is pure
crap.  It has blatant bugs that even the most novice C programmer would spot.
I can't believe that AT&T produced this code.

I don't think I should post the reconstructed source, as I don't want to get
into any kind of legal hot water.  What I *can* mention is what the bug is.

There is a function which reads the /etc/inittab file looking for a line of
the form " %s" or ":%s", where %s is the device name.  If it finds it, the
first character is set to a blank or colon, depending on whether we're turning
the getty on or off.  Now, the code that searches for the line is an infinite
loop (sound fishy?) that executes fgets() each time through.  If the fgets()
fails (i.e. the end of file is reached), the loop is broken.  However, the test
for fgets() isn't coded very well:

	char line[132];
	FILE *inittab;
	...
	for (;;) {
		...
		fgets(line, 132, inittab);
		if (line == NULL)
			break;
		...
	}
	...


Obviously, the test will never be true.  The test should only be true, however,
if the line was not found.  I don't know why it *wouldn't* be found, if the
inittab file was left alone by the user.  I tried logging what /etc/inittab
looked like when setgetty hung when it was called, but couldn't see anything
strange.

My solution to the problem was to recompile /usr/bin/setgetty with the above
code fragment changed to:

	if (fgets(line, 132, inittab) == NULL)
		break;

We haven't had any problems since.  However, the rest of the program is still
poorly written.  I would re-write the whole thing, if I had the time.
-- 
Andrew Scott
andrew@teletron.uucp	or	..alberta!teletron!andrew