Replacing constant issue[core]

[redmi111]

I noticed this bug in Replace constants option. When the replace constant is unchecked the values on constant fields are properly decoded (but lose R classes info as we're not replacing constants) and when I check that option R classes constants are properly decoded but the constants in the fields are lost (not decoded I mean not available).

Example:

In the above pic Take a look at the CHARSET field and it actually with the Replace constant checked but since there is a constant value available in bytecode it uses STRING_CHARSET_NAME but when there is no such available in bytecode the field declaration was empty.

Above one is with Replace constant unchecked.

[skylot]

@redmi111 do you want an option to enable only R constant replacement?

[redmi111]

That might actually avoid this issue but not sure if it also will replace other constants properly.

[skylot]

will replace other constants properly

I don't see any improper replace in your example. Can you point me which parts are incorrect?
I agree that sometimes constant replaced with one from another context, but constant value is always correct. At least I don't see incorrect constants yet.

[redmi111]

There are no incorrect replacements but missing replacements for a few fields where there is no value from any context.

For example take a field like below,

private static String TAG = "TAG"; -> When replace constant unchecked
It becomes like,

private static String TAG; -> When replace constants was enabled. Here it is missing the value for that field.

Actually, this doesn't happen every time (as long as the value was found somewhere in the code, it can be in a different class or in the same class different field) When there is no value found for it then it skips that.

[MrIkso]

@redmi111, look at the byte code and be surprised that if the final field is static, then a reference to it is not used, but the value is taken immediately. I don't see critical bug here.

[skylot]

@redmi111 I commit a fix for a missing field init values. This issue depends on processing order and occur if several thread used for decompilation. Not sure if it was your issue, so please check latest unstable build.