rab@alice.UUCP (Rick Becker) (11/15/84)
> Try the following in S: > > > a<-1:5 > > for(i in a) print(i) > > for(i in 0+a) print(i) > > for(i in a) print(i) > > > The results which I get seem mystical & mystifying. I'd appreciate hearing > if anomalies occur at other installations (or if the mystery is peculiar to > ours). Also explanations and/or fixes would be welcomed. > You have found a bug. Fortunately the fix is simple. Change the file $M/funev.r as follows: 50c50,52 < if(intern) { #clear up the stack, keeping only the function value --- > if(intern & !streq(TEXT(fname),TSTRING(newblt))) { > # clear up the stack, keeping only the function value > # newblt must not have its storage freed and then reload the executive. That should fix things. ----- The reason for the bug is that whenever an internal function is executed funev tries to free-up any storage the internal function may have used. "for(i in a)" invokes the newblt() function giving it as one of its arguments a DATASET entry named "a". $M/gtinst is called by infun when trying to evaluate newblt, and it is the routine that actually reads the dataset. newblt puts the pointer to the data on the stack, but when it returns, funev pops the stack and the space that once contained the dataset is now free to be overwritten by anything else that wants it. If the expression in the for() is a computed expression rather than a dataset name, the expression is already on the stack, and hence it is not bothered by the freeing operation. -- Rick Becker alice!rab research!rab
rolf@natmlab.OZ (Rolf Turner) (11/27/84)
Try the following in S: > a<-1:5 > for(i in a) print(i) > for(i in 0+a) print(i) > for(i in a) print(i) The results which I get seem mystical & mystifying. I'd appreciate hearing if anomalies occur at other installations (or if the mystery is peculiar to ours). Also explanations and/or fixes would be welcomed. Address (in case the header is incomprehensible): ....decvax!mulga!rolf:natmlab