DecompileOptions: adding missing scripting API calls that are configurable in the GUI

[palmarci]

Hello Ghidra Team!

I was recently looking at the scripting API for the DecompileOptions class and found that the Integer Format option gets read up from Tool Options, however it had no public getter/setter call.

I checked the other private members of the class and found a few missing. I don't know if it is intentional or not, but I created all the missing calls.

I have tested (only) the setIntegerFormat() call:

Test script

import ghidra.app.script.GhidraScript;
import ghidra.app.decompiler.*;
import ghidra.program.model.listing.*;
import ghidra.program.model.address.Address;
import ghidra.util.task.ConsoleTaskMonitor;
import ghidra.app.decompiler.DecompileOptions.IntegerFormatEnum;

public class TestIntegerFormat extends GhidraScript {

    @Override
    public void run() throws Exception {

        Program program = currentProgram;
        if (program == null) {
            printerr("No program is currently open.");
            return;
        }

        // Set up decompiler options
        DecompileOptions options = new DecompileOptions();
        

        // ********* CHANGE THIS LINE TO CHANGE INTEGER FORMAT *********
        //options.setIntegerFormat(IntegerFormatEnum.Decimal);
        options.setIntegerFormat(IntegerFormatEnum.Hexadecimal);



        // Create decompiler interface
        DecompInterface decompiler = new DecompInterface();
        decompiler.setOptions(options);
        decompiler.openProgram(program);

        // Get function
        Function function = getFunctionContaining(currentAddress);
        if (function == null) {
            printerr("No function found at entry point.");
            return;
        }

        // Decompile function
        ConsoleTaskMonitor monitor = new ConsoleTaskMonitor();
        DecompileResults results =
            decompiler.decompileFunction(function, 60, monitor);

        if (!results.decompileCompleted()) {
            printerr("Decompilation failed.");
            return;
        }

        // Print decompiled C code
        String cCode = results.getDecompiledFunction().getC();
        println("=== Decompiled Entry Function (Hex Integers) ===");
        println(cCode);
    }
}

Both the createJavadocs and buildPyPackage builds run fine and the new calls appear in the documentation.

[dragonmacher]

This may work for using the Decompiler outside of the UI, such as in a script. But, if this change is meant to work with the main decompiler in the tool, then you will run into the issue of keeping the DecompilerOptions in sync with the tool options. It appears as though the Decompiler will initialize from the tool options in a couple different scenarios, such as when memory blocks are added and removed, an undo/redo happens or when a user changes the options. This means that your script can change these options, but some user actions may then overwrite them later when these other events happen.

Currently, I'm guessing that script writers change the Tool Options when use the main tool's Decompiler.

[palmarci]

Thanks for the clarification. My use case is running headless analysis on a server. The PR was intended to fix the decompiler's default option "best fit", which causes inconsistent behavior - although useful for a human looking at the GUI.

What do you recommend moving forward? Is the PR acceptable in this state? Or the workaround should be editing tool config file manually?

[dragonmacher]

There is nothing wrong with this PR at first glance. Assuming there are not documentation spelling or grammatical issues, then I think this is good.