Unexpected behavior of LOCAL

[Wanderer]

I ran the following test only in the Windows version. When two functions have a LOCAL variable with the same name, and of them calls the other one, the second function seems to adopt the value of this variable as the calling function set it, instead of initializing a new variable. The output of the following program was:

"Test 1 should not see this. I am Test 1."

x$ = @Test2$()
Print x$
End

Function Test1$()
  Local temp$
  temp$ = temp$ + "I am Test 1."
  Return temp$
End Function

Function Test2$()
  Local temp$
  temp$ = "Test 1 should not see this. "
  Return @Test1$()
End Function

However, Function Test2$ did not "see" the changes Test1$ made to temp$; so in this respect it worked as expected. When I changed Test2$ in the following way, it printed only: "Test 1 should not see this."

Function Test2$()
  Local temp$
  temp$ = "Test 1 should not see this. "
  a$ = @Test1$()
  Print temp$
  Return a$
End Function

[Markus Hoffmann]

Well, it looks like everything worked as it should. LOCAL does not initialize the variables. Its value is undefined (and happens to be a copy of the global variable with the same name). If you need to initialize a local variable, you would need to use CLR after LOCAL. Maybe this should be mentioned in the manual.

[Wanderer]

So there are no "really" local variables in X11-Basic? (In my test program, there is no global variable named temp$. All occurrences of this name are inside function definitions.)
Normally (i.e. in other programming languages) "local" variables allocate their memory space in the stack frame of the respective function at the moment it is being called. This guarantees that local variables are completely encapsulated within their respective functions, and a local variable within one function is completely independent from local variables within other functions (and even from the local variables of other instances of the same function, if called recursively), since every instance of a function allocates its own stack frame.
If X11-Basic copies global variables instead, then they should not be called "local", in my opinion. You will then have conflicts not only between "local" variables of different functions (if they happen to have the same name), but also between different instances of a recursive function, because their local variables will then actually not act as "local", but as "static".
The same thing would happen if you allocate a new pointer (or string descriptor) for every instance of a function, but let it point to the same memory location as the variable from a previous instance (or from another function which uses a variable with the same name, which is probably what is happening here). This creates "static" or "shared" variables, but not really "local" ones.

[Markus Hoffmann]

No, These are indeed really real local variables. The only thing is, they are created exactly when the LOCAL statement is reached and they are not initializes. (As any local variable, which is allocated somewhere on the stack, even in C.) The frame of the local variables is only the procedure or function they are used in.

Inofficially, knowing the internas of X11-Basic, you can access (read and write) the (more) global variable before the LOCAL statement, after the local statement, the new local variable has a copy of the content of the (more) global variable. For normal programs you should not use this feature.

There are no compiler directives in X11-basic, because it is an interpreter. The compiler xbbc is independant of that and uses only commandline parameters (and defaults on Android). This is also the reason, why MERGE is not a directive but a real COMMAND. It is not like #include or so.

[Wanderer]

Thank you, this makes it clearer. So after initializing a LOCAL variable explicitly, it is no longer related to any global variable and there should be no more conflicts with other functions or function instances.