PDA

View Full Version : Fixing the Parser Scoping Issues



ZoriaRPG
01-08-2017, 11:43 AM
DarkDragon: In looking for ZScript parser bugs to fix, I would consider this scope bug to have a rather high priority, as no-one was ever able to resolve it:



ffc script foo{
void run(){
int x = 10; int w;
for ( int q = 0; q < x; q++ ) {
if ( q % 5 == 0 ) {
int y = q * 2;
w += y -q;
}
}
}
}


The issue, is that using this example...

1. The value' q', declared in the for loop, uses stack space, perpetually. It is only available to the scope of that for loop, and the if statement, but it always uses a register. This particular issue has ruined the day of many scripters, who declare for loops in scripts, and expect variables to only be in use when their scope is active. Repeated declarations of a loop condition, particularly in for loops, will cause stack overflows.

2. Likewise, the variable 'y' is only available to the scope of one if statement, and yet, it also eats up stack space at all times. Essentially, any variable declared inside the scope of a function, even at a lower scope such as a statement, is not released until the function exits.

3. Because run() is a function, and it never exits, variables inside these scopes in scripts eat up stack space at all times.

Clearly, variables at the run() scope need to remain in use, but variables declared at lower scopes should pop off the stack when their scope exits; yet they do not at present behave in the expected manner. This is an easy way to confuse scripters when the stack overflows from no apparent cause, because they expect variables to pop off that never do.

I don't know if you can give this any attention, but it is one of the more serious flaws in the parser.

At present, most of us just try to train users to declare arrays at the scope of run() and never declare loop operators at a scope lower than run(). THis is a very bad system for handling an issue of this sort, as you can likely imagine. Any ideas on how to resolve this one?

DarkDragon
01-08-2017, 03:04 PM
Ok. The current behavior is like C: nested blocks delimit variable scope, but there is only one stack frame, created on function entry and destroyed on function exit. This is not a bug, but I do see why it limits the complexity of individual functions given the fixed stack size.

What you want is something like C++, where variables are actually destroyed, and not merely inaccessible, when they go out of scope. This is not entirely trivial, but also, not impossible: when it comes time to assign stack offsets to local variables, instead of just laying them out in linear order on the stack, you put them into a tree with one scope block per tree node, and allow tree siblings to share stack space.

I'll put it on my short list.

ZoriaRPG
01-08-2017, 04:34 PM
Ok. The current behavior is like C: nested blocks delimit variable scope, but there is only one stack frame, created on function entry and destroyed on function exit. This is not a bug, but I do see why it limits the complexity of individual functions given the fixed stack size.

What you want is something like C++, where variables are actually destroyed, and not merely inaccessible, when they go out of scope. This is not entirely trivial, but also, not impossible: when it comes time to assign stack offsets to local variables, instead of just laying them out in linear order on the stack, you put them into a tree with one scope block per tree node, and allow tree siblings to share stack space.

I'll put it on my short list.

If you didn't know, I brought this up because the present method of handling scoped vars, leads to potential crashes, stack corruption, and at the best, script failure. Scripters who do not know to use a single variable for multiple for loops, as an example, and to refresh it with each new loop typically have resulting stack errors when a dozen loops with similar variables flood the stack as every variable is allocated as soon as the script runs. Obviously, array use is preferable in general, but if there is a resolution to this, it would clean up some issues that aren't pretty.

DarkDragon
01-08-2017, 05:06 PM
Sure. It's a clear problem, whose solution doesn't affect old quests, doesn't touch the .qst file format, and doesn't introduce any new features needing future support. A home run in my book :)

DarkDragon
01-10-2017, 12:28 AM
I think this is working. I've pushed it to the experimental DD/zscriptstack.