Sign In

Commands can "return" variables

#1✎ 943snail_HelperReceived for being very helpful around SmileBASIC SourceAchievementsOSP Contest 2 Contest ParticipantI participated in the second SmileBASIC Source OSP Contest!Night PersonI like the quiet night and sleep late.Express YourselfI was coding in the wee hours and apparently felt particularly sloppy with the code I was writing. I ended up writing something similar to this.
DEF THING
VAR T%
'does some stuff
RETURN T%
END
It took me far too long to find the actual issue with this code because the compiler has some trouble deciding what to do sometimes. If you haven't noticed the issue yet, don't feel bad, the parser didn't either.
The DEF THING is a command, and the code was written so that it would return a value. Despite the fact that commands can't return anything, this compiles perfectly fine!
The bug is this: if you try to use a RETURN statement in a command- or OUT-form DEF to return either a variable or a label, the compiler acts as if it's a bare RETURN statement (you're returning nothing.)
This is in fact a compile-time and not a run-time bug because if you enable OPTION STRICT and a variable is specified, it doesn't even check if the variable exists! The compiler just throws out whatever variable you passed to the RETURN.
When I say it has to be either a label or a variable, I mean this exactly. Trying to pass a number or a string throws Syntax error, as it should.
It should be noted that using a RETURN without an argument is perfectly legal in a command or OUT; it simply exits the DEF, as with a GOSUB.
Upon execution, the DEF behaves as you would expect, because commands don't return anything and the compiler just throws out the return value.
Posted 3 years ago

#2✎ 169012Me21Syntax HighlighterReceived for creating the code syntax highlighter on SBSNight PersonI like the quiet night and sleep late.Express YourselfThis isn't actually a bug.
What happens is that RETURN in a function without a return value doesn't accept any arguments.
RETURN T% is actually being interpreted as RETURN:T%, where T% is a function call (even though the function T% probably doesn't exist)
The reason this doesn't cause an error is because it doesn't check if T% is a valid function until it reaches it, which never happens because the RETURN.
Posted 2 years ago
Edited 2 years ago
by 12Me21