Le Dimanche 19 Février 2006 11:45, nicolas cellier a écrit :
> So i started inquiring bytecode generation and found this: the DEDA you are
> speaking of also have a limitation to 256 variables. And i did not see
> these limitations enforced anywhere in the code.
> Only the single byte code limit is tested for in LeafNode>>#code:type:, and
> the code for DEDA is temporarily encoded (type*256+index). Should index
> overpass the 256 limit, there might be strange results, changing the type
> of operation and probably crashing the VM...
>
> Protecting this code would be easy
> (index > 255) ifTrue: [self error: 'bycode limit exceeded'].
>
> Maybe i missed a protection elsewhere ? I will try to exhibit a test case
> latter.

I answer to myself: it seems that the case cannot happen:

number of inst var is protected at class creation
at ClassBuilder>>#computeFormat:instSize:forSuper:ccIndex:

number of literals is protected at
MethodNode>>#generate:

number of temps (and/or args) is protected at: 
CompiledMethod>>#newBytes:trailerBytes:nArgs:nTemps:nStack:nLits:primitive:

However tricky as i can be, i saw that automatic temporaries allocated for 
optimizing to:do: loops are not counted in this last protection.
So i gathered 64 declared temps and a to:do: loop, and i reached code
  self halt.  "Shouldn't get here"
in TempVariableNode>>#sizeForStorePop:

I am close to the bug, but cannot reveal it because the limit of temporaries 
is not 256 as i stated incorrectly but 64. That's what i call luck.

So no need to protect again in LeafNode>>#code:type:

However, i would really prefer a notification of exceeded number of temps 
rather than this delicious halt with shouldn't get here comment...

By the way, if i proceed the halt, i am saved from crash by a MNU 
#adaptToInteger:andSend:.

I did post on mantis (http://bugs.impara.de/view.php?id=2920) for that.
I did not include a patch: better think of rewriting some part of code 
generation rather than patching.