On 30 Jul in article <159f2d9858...@ArmX6.adamshome.org.uk
Sorry - been busy (which is nice for a change).
> > I have a weird problem.
> > What can undefine a variable in this way?
> I've now fixed it. The problem was caused by an incorrectly sized
> The bit that still puzzles me is how *reportstack within the
> routine showed a parameter being passed in, yet immediately before
> and still within the routine *report showed one of the parameters
> as not defined.
> > The called function:
> > DEF PROCFD_SET(n%,p%)
> > IF DEBUG%AND1 THEN
> > *report SL: fd_set: n% p% (n% DIV 32) (n% MOD 32)
> > *REPORTSTACK
> > ENDIF
> > p%!((n% DIV 32)*4) = p%!((n% DIV 32)*4) OR (1<<(n% MOD 32))
> > ENDPROC
> > The reporter result
> > SL: fd_set: n%=14 p% (n% DIV 32)=0 (n% MOD 32)=14
> > BASIC Stack
> > 661 PROCFD_SET(14,&00092390) [in "Libraries.Slalom_Comms_Lib"]
> > 11:23:43.17 ** BASICError ** ERR=4 Mistake ERL=435 [in
Yo do not clarify what line 435 is ... but I suspect it is the line
above before the ENDPROC?
The 'Mistake' error puzzled me, but then I realised if p% is missing
then because it is on the LHS of line 435 that is the error you see.
The *ReportStack command is showing the value of the *parameters*,
which it gets from a pointer held on the stack to the values and
types of the formal parameters of the routine. It does not have to
look up the variable names. It seems that the values themselves are
correct, so have not been overwritten.
While executing line 435 BASIC will look up the variable names, and
if any of the linked lists for the initial letters of any of the
variables has been corrupted (eg by a buffer overwrite), then the
results are unpredictable.
After a spate of memory overwrites (which can cause some very strange
things) I did consider writing some sort of BASIC Heap validation
check, but never did.
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.