On 29/06/2021 11:44, Bob Spelten via Ql-Users wrote:
Wolfgang Lenerz via Ql-Users wrote:
Hi,
in my experience, this is often caused by a Basic extension not
resetting the stack correctly. This generally seems to be the case
either when a keyword changes the value of an entry parameter, to make
it into a return parameter, or when a function returns a value (very
often a string).
But without having a complete program to test, this will be
difficult to
find out.
Thanks for the suggestions.
My function does not change any of the entry parameters, only sets
the return value. I have written other functions that do the same
but without this anomaly, also with 8 chr names.
Anyway I will check the exit section to see what I did differently
from previous and consult the Assembly Language PDFs to get it right.
Bob,
If theres no problem with your S*BASIC structure (which I presume is
the case since youre desperate enough to write here) then the problem
must almost certainly be with one of the extensions used. A problem
with SBASIC itself is possible but even less likely.
A string function is the most likely culprit as its easy to make a
mistake with the return stack, but as Wolfgang mentioned, it could
also be a bplet issue. My usual test rig for any function I write
looks something like this:
rem Testing the function TEST$
m = free_mem: mm = m
for i = 0 to 9999
:
t$ = 'x' & TEST$('abc')
t$ = TEST$('abc') & 'x'
t$ = 'x' & TEST$('abc') & 'x'
:
t$ = 'x' & TEST$('abcd')
t$ = TEST$('abcd') & 'x'
t$ = 'x' & TEST$('abcd') & 'x'
:
if m <> free_mem then
print m - free_mem
m = free_mem
endif
endfor i
print 'Memory eaten:'! mm - free_mem
A healthy function should never eat memory as it goes! A function like
that may well mess up the interpreter's return stack.
NB: The routine may crash the system if theres a serious problem with
the function. But at least then youll know.
HTH, Per
_______________________________________________
QL-Users Mailing List