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

Reply via email to