This PR fixes the issue where anything over 255 functions will cause errors by calling the wrong functions.
The problem: any function number over 255 will cycle back to 0, thus calling the wrong builtin function. There is no warning.
In much of current toaststunt (Lambda) code, function IDS are stored as 2-byte integers with exception of the bytecode which is the function call, proceeded by the function ID.
This fix changes this, so that the function call can be proceeded by a two-byte function ID.
The problem with this fix which I could not resolve is that of queued tasks.
If a DB is dumped with queued tasks, the PC is stored along with the code for that specific task at the point when it was started.
The server will then parse and recompile the current program, and substitute the bytecode into the vm for that task. The PC will then point to the proper place.
Given that we've just updated the function calls, this means that the PC will be off by however many function calls exist -before- the PC. I could not find a clean or safe way to adjust this pC without crashing, so this PR should be held until we can find a way to do this, or until we tell everyone they must kill tasks and then reload the db before respawning. The latter solution is far from my favorite.
test steps:
Load any server with more than 255 builtins.
Write a test verb and call builtin 256 and 257 in your list. compile the verb, and @list it.
If the builtins list properly, that means that the fix works; previously simply compiling the verb would translate the function calls to whichever in the list was at the value that the single byte wrapped around to.
This PR fixes the issue where anything over 255 functions will cause errors by calling the wrong functions. The problem: any function number over 255 will cycle back to 0, thus calling the wrong builtin function. There is no warning. In much of current toaststunt (Lambda) code, function IDS are stored as 2-byte integers with exception of the bytecode which is the function call, proceeded by the function ID. This fix changes this, so that the function call can be proceeded by a two-byte function ID. The problem with this fix which I could not resolve is that of queued tasks. If a DB is dumped with queued tasks, the PC is stored along with the code for that specific task at the point when it was started. The server will then parse and recompile the current program, and substitute the bytecode into the vm for that task. The PC will then point to the proper place. Given that we've just updated the function calls, this means that the PC will be off by however many function calls exist -before- the PC. I could not find a clean or safe way to adjust this pC without crashing, so this PR should be held until we can find a way to do this, or until we tell everyone they must kill tasks and then reload the db before respawning. The latter solution is far from my favorite. test steps: Load any server with more than 255 builtins. Write a test verb and call builtin 256 and 257 in your list. compile the verb, and @list it. If the builtins list properly, that means that the fix works; previously simply compiling the verb would translate the function calls to whichever in the list was at the value that the single byte wrapped around to.