commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (BCEL-295) Incorrect live range information in LocalVariableGen
Date Fri, 13 Oct 2017 20:10:00 GMT


ASF GitHub Bot commented on BCEL-295:

GitHub user markro49 opened a pull request:

    BCEL-295 fix local variable live range length; add test case


You can merge this pull request into a Git repository by running:

    $ git pull bcel295

Alternatively you can review and apply these changes as the patch at:

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #17
commit 9bda4c39979c184c4aa73bf99c93387bbbbf30d1
Author: Mark Roberts <>
Date:   2017-10-13T20:06:11Z

    fix local variable live range length; add test case


> Incorrect live range information in LocalVariableGen
> ----------------------------------------------------
>                 Key: BCEL-295
>                 URL:
>             Project: Commons BCEL
>          Issue Type: Bug
>            Reporter: Mark Roberts
>         Attachments: LocalVariableGen.diff
> (Not sure of priority - blocker for me, but probably of little consequence for most clients.)
> There is a design flaw with the treatment of local variable live ranges.  In the .class
file these are demarcated via byte code offsets into the method's instructions.  The range
is from start up to, but not including, the length. If the live range lasts through the end
of the method, then length points to the first byte 'past' the end of the method.  BCEL converts
these offsets into InstructionHandles and in doing so can no longer differentiate between
a live range that ends prior to the last instruction of the method or one that includes the
last instruction of the method.
> How to fix this is a bit of a problem.  The 'correct' solution would seem to be to keep
end as a null InstructionHandle as indicated by some of the comments.  Unfortunately, LocalVariableGen
does not have access to the method's InstructionList and thus cannot easily convert this null
pointer back to the correct length for output.  We could grab the InstructionHandle for start
and then count the instruction bytes as we iterate to the end.
> But all this still begs the question of the fact this would be a change in behavior -
a client would now have to check for a null end handle before dereferencing.  The proposed
fix I have attached takes another approach.  It sets a flag in the constructor if the initial
value for end is null and then lets all else proceed unchanged.  A client may test this flag
to see if the special case is active.  Also, the getLocalVariable method uses this flag to
correctly set the length on output.  
> I believe this approach would have no effect on existing code.  We would only need to
document the new flag for clients that might care.

This message was sent by Atlassian JIRA

View raw message