RFC: Limit use of global variables in CLEO scripts

[x87]

• it does not respect boundaries set by CustomArrays.ini even when this option is enabled
• it treats all variables as 4 bytes, even str8 and str16 variables
• using a high numeric var like $12000 allows to start allocating from 12001, but it requires comping as a command, there is not compiler setting otherwise (maybe repurpose alloc(...) for that?)

[x87]

as a quick workaround we can fill all the holes in CustomVariables.ini with dummy names and take up all unused slots. But it will produce unexpected results if someone used same indexes directly (e.g. $405) - is this OK?

[x87]

relying on CustomVariables.ini for allocation can be problematic for custom main.scm, especially those of a smaller size. CustomVariables.ini only matches the layout of main.scm V1

[x87]

restricting use of custom global variables in cleo scripts is tempting but does not solve any issue:

• people will use existing predefined names instead for their data
• they will use random numeric variables ($1234) or allocating random indexes (alloc($myvar, 1234)) interfering with main.scm data again
• it creates more confusion around the choice of names: why are some names (defined in CustomVariables.ini) allowed, and some are not

[x87]

Suggested changes to raise awareness of potential issues cause by mis-use of global variables.

1. restrict use of global variables in CLEO scripts by default. User should explicitly opt-in by using directive {$UNSAFE_USE_GLOBAL_VARS}. UNSAFE_USE_GLOBAL_VARS is implicitly on when SB3_Compat option is on (current default in 4.0-4.1, but will change in the future.)
2. no implicit allocations. User allocates each variable by using Alloc function.
3. Numeric variables are not allowed ($1234), use Alloc instead
4. Convert CustomVariables.ini data to the include file GlobalVarsV1.txt with set of Alloc instructions (e.g. Alloc($player1, 2)). User can import this file to use known indexes. This file can include {$UNSAFE_USE_GLOBAL_VARS} by default.
5. You can't allocate another variable to index taken by standard variables, e.g. Alloc($myVar, 2) will throw an error.
   5.1. Allocating variables to index 0 and 1 will throw an error
6. ADMA syntax (&0, &1234) is allowed without limitations

Scenario 1

I want to use the existing global variable, like $ONMISSION, $PLAYER1

I add

{$I GlobalVarsV1.txt}

Scenario 2

I want to use a new global variable, like $myVar

I add {$UNSAFE_USE_GLOBAL_VARS} if SB3_compat is off
and
use Alloc($myVar, <some index>)

<some index> should not match any standard variable index, also should be within allowed range for global vars.

Scenario 3

I want to use some explicit index like $1234

it is not allowed.

[MiranDMC]

I think named global variables should be accessible as is, without need of extra includes or directives. That's what mode is for, it defines environment.
Otherwise already de compiled main will no longer work. Using variables like $player or $onmission would get unnecessary complicated too.

Not sure about numbered variables like $1234. I tend to use these, but I started to think I would be much better now if I was forced to actually define them, instead being lazy and using magic numbers. This is probably case for {$UNSAFE_USE_GLOBAL_VARS}

Alloc directive should be updated to accept type, as now definition of single variable has to be split in two lines.

Variables declared by mode should have declared types. It would make possible to use class syntax with $player1 and $scplayer. Decompiled main would also look better, as now it mixes both styles.

[MiranDMC]

Just add compilation error for CS scripts like:

Sanny Builder 4 - compiler error
Global variable "$PLAYER_CHAR" is not defined in current edit mode.
Select existing global variable name or define an new one using Alloc directive.

https://docs.sannybuilder.com/language/data-types/variables#global-variables

Using Alloc or explicit numbered variable like $401 forces user to pick some number, possibly leading to realization that it might be already occupied.