pxb1988
commented
9 years ago yes, seams dex2jar is buggy on the 'constructor' var.
the different between dex2jar and smali is that the token sequence is different
- for dex2jar, the token sequence is (6 tokens)
.fieldprivatefinalconstructor:Lcom/google/mygson/internal/ObjectConstructor; - and for smali the token sequence is (4 tokens)
.fieldprivatefinalconstructor:Lcom/google/mygson/internal/ObjectConstructor;
the constructor token is greedy eat by sAccList
ClockerZadq
If a field is named as some special word, e.g. 'constructor', as the following shows
.field private final constructor:Lcom/google/mygson/internal/ObjectConstructor;
The small parser would complain as the title shows.
I think there should be some bug in the ANTLR rule 'sField', and perhaps other rules quote rule 'sAccList' are also the same.
sField : '.field' acc=sAccList (f=sFieldF|f=sFieldP) ('=' v=sFieldValue)? (sAnnotation* '.end field')? ;
As in the above-mentioned case, the token 'constructor' will be matched as a ACC because rule 'sAccList' is greedy and it will not go into the following rule to be matched as a field name.
I'm a newbie to ANTLR. It seems Apktool use the same rule to parse a field declaration, but it's surprising it works fine. And I also tried to change rule 'sAccList' into a nongreedy rule, but I failed.
I'm sorry I'm also a newbie to Github and I even don't know how to highlight the code snippet. I hope the information above could help you!