> it seems that: a) bcel in fact does not look at variable scopes when > giving you a local variable number; and b) it doesn't adjust max_locals > when giving you a local variable, so you'll have to call setMaxLocals > even if you use this technique
According to lines 288-291 the max_locals is adjusted when necessary. For this to work a consistant/valid max_locals should be present because this is used so calling setMaxLocals() before calling addLocalVariable() would be good idea. So if local variables are only added by calling addLocalVariable an invocation of setMacLocals() could be omitted, I think. 288: int add = type.getSize(); 289: 290: if(slot + add > max_locals) 291: max_locals = slot + add; I think the misunderstanding is raised by the fact that the max_locals int value is used as the next index and thus is actualy 1 higher (getMaxLocals returns int n, thus the slots 0 to n-1 are taken and the next is n) > I'm pretty sure the start and end arguments to addLocalVariable are > required becuase this info ends up in the local variable table for the > method, not becuase bcel has any interest in knowing internally where > particula rvariables are in scope. > also, your code uses start == null and end == null in addLocalVariable, > so even if bcel took scopes into account in assigning lv indices, it > would have to assign different indices to sss and rrr. Yeah that's true, indeed. The BCEL developers could solve this by using the convention that getIndex() can only succeed if both scope boundaries are set and otherwise raise an exception or something. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
