Evaluating function's return value within it causes program to crash.

[oitofelix]

Describe the bug
If the local variable that has the current function's name (and its current return value) is used in an expression the program immediately crashes.

To Reproduce
Run the following program:

PRINT f

FUNCTION f ()
  f = f + 1
END FUNCTION

Expected behavior
Although this was not allowed in QBasic/QuickBasic, later versions of Microsoft Basic implement this feature. Ideally, I think its use should be allowed, because it's useful and probably won't introduce any compatibility issues. Otherwise, it should just cause a compilation time error.

Desktop (please complete the following information):

• OS: Debian GNU/Linux
• Version QB64PE 3.14.1

[a740g]

This is working as designed. The function f() recursively calls itself unconditionally until the stack overflows. Run the following to observe what’s happening:

PRINT f

FUNCTION f ()
    PRINT "Entered f()"
    _DELAY 0.1!
    f = f + 1
END FUNCTION

[oitofelix]

Oh... now I see. Thanks!

I remember (incorrectly?) using Visual Basic for Applications and being able to reference the implicitly defined local variable that holds the return value of the function like any other variable, without this recursive calling behavior, since the references didn't have the function call operator "()". Unfortunately this behavior, even if implemented, wouldn't be totally compatible with the current syntax/semantics (but it's not so far off).

Considering the given example, in QB64, if we define F taking any argument, the compiler complains about the wrong number of arguments being passed to the function, when not using the call operator. Indeed that's is consistent with the designed behavior, as you said.

Shouldn't, however, the program pop up a dialog box telling the stack has overflown, instead of failing silently?

[a740g]

I remember (incorrectly?) using Visual Basic for Applications and being able to reference the implicitly defined local variable that holds the return value of the function like any other variable, without this recursive calling behavior, since the references didn't have the function call operator "()". Unfortunately this behavior, even if implemented, wouldn't be totally compatible with the current syntax/semantics (but it's not so far off).

I have not used VBA, but I have worked with legacy Visual Basic (which I guess is similar in many ways). However, it's been a long time since I last used VB, so I don't recall if it allowed referencing a function's return value as a variable in the way you're describing.

Shouldn't, however, the program pop up a dialog box telling the stack has overflown, instead of failing silently?

That's a good point. It would certainly be more helpful if the program alerted the user about a stack overflow, rather than failing silently.