Skip to content

Decompiler: implement operator associativity handling#9092

Open
liamwhite wants to merge 1 commit intoNationalSecurityAgency:masterfrom
liamwhite:decompiler-operator-assoc
Open

Decompiler: implement operator associativity handling#9092
liamwhite wants to merge 1 commit intoNationalSecurityAgency:masterfrom
liamwhite:decompiler-operator-assoc

Conversation

@liamwhite
Copy link
Copy Markdown

@liamwhite liamwhite commented Apr 1, 2026

Currently if you define some structures like this:

struct astruct_vtable;

struct astruct_data {
    ulong m_member;
};

struct astruct {
    astruct_vtable *v;
    astruct_data d;
};

(my general approach to modeling C++ inheritance), and then run it through the decompiler, you get this:

ulong member_test(astruct *param_1)
{
  return (param_1->d).m_member;
}

where the left subexpression is unnecessarily parenthesized.

This occurs because the source printer sees they have equal precedence, and thinks there is a conflict because the token types are not the same. In the decompiler's current model, operators can only be self-associative. However, though they do share the same precedence, both direct member access (.) and pointer member access (->) are actually left-to-right associative. (Associativity is similar in Java.)

The proposed change makes all operators have an explicit associativity direction associated with them, which removes the gratuitous parentheses:

ulong member_test(astruct *param_1)
{
  return param_1->d.m_member;
}

@astrelsky
Copy link
Copy Markdown
Contributor

Thank you! I've always hated this 😂.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Feature: Decompiler Status: Triage Information is being gathered

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants