Using getBytes with Python script broke with Jython->PyGhidra migration

[niooss-ledger]

Hello,

Last year I have written some Python scripts which invoked getBytes(addr, size) (from FlatProgramAPI). It ran fine with Jython on Ghidra 11.3.2 and 11.4.x.

Testing the same scripts from the PyGhidra window in Ghidra 12.1.2 now reports a Python exception:

TypeError: No matching overloads found for ghidra.program.flatapi.FlatProgramAPI.getBytes(ghidra.program.model.address.GenericAddress,JLong), options are:
	public final byte[] ghidra.program.flatapi.FlatProgramAPI.getBytes(ghidra.program.model.address.Address,int) throws ghidra.program.model.mem.MemoryAccessException

The failing code is a loop which reads bytes between addresses with references:

    for block in currentProgram.memory.blocks:
        start_addr = block.getStart()
        while start_addr.compareTo(block.getEnd()) <= 0:
            # Find the next cross-referenced address
            next_addr_with_ref = currentProgram.getReferenceManager().getReferenceDestinationIterator(start_addr.add(1), True).next()
            if next_addr_with_ref is not None:
                max_length = next_addr_with_ref.subtract(start_addr)
            else:
                max_length = block.getEnd().subtract(start_addr) + 1
            data = getBytes(start_addr, max_length)  # <- this line triggers exception TypeError
            # ...

The issue is that max_length is a JLong while getBytes expects an int:

ghidra/Ghidra/Features/Base/src/main/java/ghidra/program/flatapi/FlatProgramAPI.java

Line 2006 in f9e1384

public final byte[] getBytes(Address address, int length) throws MemoryAccessException {

As it is very unlikely that length gets over 2GB, I can imagine why this function takes an int instead of long. Nonetheless this means that instead of writing:

data = getBytes(addr, end_addr.subtract(addr))

... PyGhidra now requires adding an explicit cast to int:

data = getBytes(addr, int(end_addr.subtract(addr)))

Here are 2 questions:

1. Is this a bug? Or said differently, would Ghidra developers be open to change the type of length in function getData to long? Is this kind of inconsistency in scripting API considered as something which can be improved in the future?
2. In Python 3, type int can actually hold any arbitrary large integer (contrary to Java int). Would it make sense to make Address.subtract's Python binding return an int instead of a JLong? Or to define a method __sub__ such that subtracting two addresses (with a1 - a2) returns a Python int?

What do you think?

[krotname]

This looks like an expected PyGhidra/JPype type-boundary issue rather than a change in FlatProgramAPI behavior.

The Java signatures line up with the error:

• FlatProgramAPI.getBytes(Address address, int length) allocates new byte[length]
• Address.subtract(Address addr) returns a Java long
• PyGhidra uses JPype, so the return value crosses into Python as a Java long-like object, not as something JPype will automatically narrow to Java int for overload resolution

So the explicit conversion is the right workaround:

max_length = int(next_addr_with_ref.subtract(start_addr))
data = getBytes(start_addr, max_length)

I would add a guard if the range is computed dynamically:

max_length = next_addr_with_ref.subtract(start_addr)
if max_length > 0x7fffffff:
    raise ValueError(f"range too large for FlatProgramAPI.getBytes(): {max_length}")
data = getBytes(start_addr, int(max_length))

Changing getBytes(..., int) to long would not buy much unless the implementation also changed, because it returns a Java byte[], and Java arrays are indexed/sized by int anyway. For large ranges, chunking the read is the safer API pattern.

A Pythonic Address.__sub__ returning a normal Python int could be a nice PyGhidra convenience, but I would treat that as a feature request for the Python binding layer, not as a bug in Address.subtract() or FlatProgramAPI.getBytes().