Re: [Cp-tools-discuss] gnu.bytecode

[Elliott Hughes]

On Jan 15, 2005, at 23:51, Per Bothner wrote:

> Elliott Hughes wrote:
> > and is wrong because it doesn't properly distinguish class modifiers, 
> > method modifiers, and field modifiers.
>
> Huh?  It does - that's what the "kind" parameter to
> Access.toString(int flags, char kind) specifies.
>
> One possible nit is that it will (say) happily write INTERFACE
> for a method that erroneously has the 0x0200 bit set.  A solution
> is to define three flags:
>   static final int CLASS_MODIFIERS = PUBLIC|...|ENUM;
>   static final int METHOD_MODIFIERS = ...;
>   static final int FIELD_MODIFIERS = ...;
> and use that in the toString method.

i assume you're aware of this, but in case you're not, the 
ACC_INTERFACE on a method is just one instance of a general problem; 
ACC_ENUM also on a method is another obvious one. but using the three 
constants you mention and going back to the "if (unknown != 0)" style 
fixes all of that.

the version of gnu.bytecode in cp-tools was out of date, and only 
included the super/synchronized ambiguity. i see that kawa's copy also 
has the other two. mind you, thinking about it, it'll happily report a 
"transient" class, and that isn't right either.

perhaps the right solution is to mask the invalid ones out *first*, 
decode the acceptable ones, and then append the unknown ones. i didn't 
think of that when i wrote my alternative, which is why i went for 
three separate methods.

> I suggest you change the code to use gnu.bytecode.Access.

are you going to make the change above, or shall i?

> It might make sense to include GjDump in gnu.bytecode.

fine by me: i think it's a big mistake to have two copies of the same 
code in two different repositories. i'm happy with whatever license. 
the only lines i didn't write are the copyright notice at the top, 
which i copied from one of the other files in the same directory, just 
to fit in.

--
http://www.jessies.org/~enh/