[Cuis-dev] Bugfix: wrong bytecode when creating a class instance variable interactively

[Juan Vuletich]

Hi Facu,

Wow! Not every day you find a bug that is over 40 years old!

Just pushed this to GitHub. Thanks!

Cheers,

On 2026-10-04 1:01 PM, Facundo Javier Gelatti via Cuis-dev wrote:
> Hello!
>
> This is a bug report + fix.
>
> The bug is the following: declaring a class instance variable from the 
> "Unknown variable" popup sometimes produces a method whose bytecode 
> does not match the source (it stores into the wrong variables).
> I attach some code to see this (example.workspace.st 
> <http://example.workspace.st>), which should be run from a workspace.
>
> This happens because Metaclass>>addInstVarName: reverses the order of 
> existing variables (which is already a weird behavior), and the 
> compiler resolves instance variables to slot numbers at the start of 
> the compilation. So, in an interactive environment:
> 1. When we accept a method with an undeclared name, a notification is 
> signalled mid-compilation.
> 2. Then, from the popup, we choose to declare an instance variable.
> 3. So, Parser>>declareInstVar: sends #addInstVarName:. This adds the 
> instance variable (reversing the order of the existing ones), and 
> triggers a recompilation of all existing methods (this does not 
> include the method mid-compilation, which is not yet installed on the 
> class).
> 4. Then the compilation resumes. But the encoder has already assigned 
> a slot index to every pre-existing variable, so the system ends up 
> producing the wrong bytecode.
> Note that the class needs to have at least two existing class instance 
> variables for this to happen (since reversing just one does nothing).
>
> The fix is to make Metaclass>>addInstVarName: preserve the order of 
> the variables (as Class>>addInstVarName: already does). With the order 
> preserved, the indices the encoder computed before the declaration 
> stay valid.
>
> I've included tests for the bug, and also two additional things for 
> consistency: one test for this same thing but instance-side, and a 
> change to #removeInstVarName: to also preserve the order of the 
> variables (removing class instance variables does not produce wrong 
> behavior, but it is a bit confusing to see the order of the variables 
> change).
>
> * * *
>
> As a side-note: I've been chasing this bug for some time, since it 
> specially affected students using Cuis-University (denotative objects 
> are classes behind the scenes, so all instance variables are class 
> instance variables). The bug was hard to find because when you 
> recompile the method (e.g. make any change and recompile, or file it 
> out and then file it in, etc.), the bytecode is silently fixed.
>
> Cheers!
> Facu
>
-- 
Juan Vuletich
www.cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20261005/8c8236ab/attachment.htm>