Newsgroups: rec.arts.int-fiction
Path: nntp.gmd.de!Dortmund.Germany.EU.net!main.Germany.EU.net!Frankfurt.Germany.EU.net!howland.erols.net!netcom.com!erkyrath
From: erkyrath@netcom.com (Andrew Plotkin)
Subject: Re: MaxTADS & addword/delword
Message-ID: <erkyrathE0nw89.Ar5@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
X-Newsreader: TIN [version 1.2 PL1]
References: <erkyrathE0GK4C.Is8@netcom.com> <55r0gi$t05@newsgate.duke.edu> <564akq$bck@life.ai.mit.edu>
Date: Sun, 10 Nov 1996 15:55:21 GMT
Lines: 27
Sender: erkyrath@netcom18.netcom.com

David Baggett (dmb@xbar.ai.mit.edu) wrote:
> >I tested the fragment using the 2.2.1 runtime which recently appeared @
> >gmd.de.  Just as before, delword() didn't work.  Chalk one up for MaxTADS.

> MaxTADS is probably getting lucky.  As far as I know, there's only one
> bug fixed in MaxTADS that's not fixed in the standard 2.2.1 distribution,
> and that wouldn't (as far as I can tell) affect delword().  

Correct.

> I bet something in the TADS source is reading off the end of an array
> or other data structure, and thereby getting nondeterministic results.
> MaxTADS may just have a 23 where MacTR has a 15...  If this is the case,
> then delword may be unreliable on *all* machines.

This wouldn't surprise me.

I don't suppose anyone has any idea *where* this is occurring? Which 
piece of code actually contains the bug, so I can go look at the source 
code and see which versions have it fixed and which don't?

--Z

-- 

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
