#9503·ghidra

Incorrect treatment of sized function pointers in vtables

Author: Wall-AFCreated Aug 14, 2026Updated Sep 14, 2026
LabelsFeature: DecompilerStatus: Triage

Describe the bug When using a vtable where the member pointer size has had to be increased (eg for win16 apps to represent far pointers), direct[^1] calls to those functions are ignoring the function prototypes which is removing the calls parameters.

To Reproduce Steps to reproduce the behavior:

  1. Load in the enclosed function (from the Decompile:Panels Debug Function Decompilation menu)
  2. Examine the output
  3. See issue

Expected behavior Recognise pointers of all sizes and handle them appropriately

Screenshots

Attachments vbar_On0x7b6.zip

Environment (please complete the following information):

  • OS: Windows 11
  • Java Version: 25.0.3
  • Ghidra Version: 12.2-DEV
  • Ghidra Origin: locally built

Additional context N/A

[^1]: By direct call, I mean that Ghidra produces C like: nRes = (*(code *)(ulong)*(uint *)&((this->parent)._vtable.dlgTrainingConsoleV1)->field7_0x80)(); instead of creating a pointer to said vtable function, like: ppfVar1 = &((this->parent)._vtable.dlgTrainingConsoleV1)->field7_0x80; (**ppfVar1)(this); (still not ideal, but better). Note that in this example, Ghidra creates the variable ppfVar1 as <fnName> *32 *32 which produces the output without parameters, but by manually changing the datatype to <fnName> * *32 the correct output is produced. (More importantly, if the <fnName> prototype needs updating, calls are automatically corrected too.)

Source: NationalSecurityAgency/ghidra