Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!munnari!basser!uqcspe!mm730!probe
From: probe@mm730.uq.OZ (Cameron Davidson)
Newsgroups: net.text,net.bugs
Subject: Re: DWB tbl bug!! HELP
Message-ID: <121@mm730.uq.OZ>
Date: Tue, 4-Feb-86 20:14:17 EST
Article-I.D.: mm730.121
Posted: Tue Feb  4 20:14:17 1986
Date-Received: Thu, 6-Feb-86 21:07:57 EST
References: <98@calgary.UUCP>
Distribution: net
Organization: Mining&Metal. Eng; Univ of Qld; Brisbane; Aus
Lines: 24
Xref: watmath net.text:925 net.bugs:737
Summary: problem is not second table - caused by scribbling on input buffer

The problem arises when something scribbles 4 bytes into the input
buffer of (FILE *)tabin.
It occurs during the call to frearr() after the first table finishes printing
when the alloc'd memory is freed.
I think the problem is caused by the allocation at line 291 of t4.c
in routine garray() and the problem seems to have gone away by increasing
the allocation to 'sep' by one int.:
	sep = (int *) getcore(qcol+2, sizeof(int));
	sep++; /* sep[-1] must be legal */
Note the second line which seems to be a big hint that the program actually
uses one more.

I only *think* the problem is fixed because every time tbl is compiled -with
and without '-g' the symptom shifts and sometimes the test file then runs OK
but another one fails.

We originally got around the problem by just running this version as
'big-tbl' for those who needed more than 20 columns and took input
always from stdin - When that is done whatever was causing the problems
seemed to have no harmful effects.

Cameron Davidson
probe@mm730.uq.oz
UUCP:..seismo!munnari!mm730.oz!probe