I'm afraid Marcel is required - horrible bug in SBASICs MultiBASICs

[pjw]

<>
If the first variable enumerated when the SBASIC daughter job is parsed is then used as a formal parameter in a function/procedure, very odd things happen (TM).

The effects vary slightly as to whether that variable appears as the first formal parameter, or later (first being catastrophic, later in the param list, ignored, but upsets the structure parsing.)
<>
Good find

I can confirm theres some hanky-panky going on there! Good catch!

[pjw]

Here are two samples that isolate the issue:

Code: Select all

100 p$ = 'abc': p = 123
110 :
120 test p$, p
140 PAUSE
150 :
160 DEFine PROCedure test(p$, p)
170 PRINT fnm$, c
180 END DEFine
190 :

RUN or EXECute this in an SBASIC daughter console and see what happens! (Be prepared to RJOB or even for a system crash!)

Works fine in Job #0, and Qlib compiled. Another variant is this:

Code: Select all

100 p = 123: p$ = 'abc'
110 :
120 test p, p$
140 PAUSE
150 :
160 DEFine PROCedure test(p, x$)
170 PRINT c, x$
180 END DEFine
190 :

This may RUN ok, but cant be LRUN or EXECuted.

Ive sent a report to the Registrar to see if anything can be done.

I believe, but cannot prove, that there are other situations where, if the variable names of the calling parameter match the formal parameter name, problems can occur (inexplicable hangs, etc). I have been wary of doing so for some time now. Perhaps it was only this specific condition I was running up against yet failed to make the connection.. I dont know.

In the mean time just avoid using the same variable to call an fn/proc as the formal parameter, especially the first variable defined, just as Martyn stated.

[ql_freak]

Hi Martyn!

After a bit of playing around, I think I can more accurately describe the anomaly that you have been seeing - the below may assist who so ever takes it upon themselves to review and update the (open source) SBASIC parser in SMSQe.

If the first variable enumerated when the SBASIC daughter job is parsed is then used as a formal parameter in a function/procedure, very odd things happen (TM).
...
Good find :-)

 
Wow! Excellent job! Thank You very much!

I think the best solution is to always define variables with names, which hopefully no one will ever use, e.g.:

Code: Select all

1 __hps__4afb__=1:__hps__4afb__$='':__hps__4afb__%=0

Edit:
Just tested, does unfortunately not help. I.e. one must be careful with formal parameter names. I think I from now on will use the convention to add an underscore to all formal parameters e.g. instead of c% using c_% and do not use names with one added underscore in other SBASIC-code.