Decode input data with bad padding

[ArielTM]

We want to decode input data sent to old contracts compiled using solc 0.5.16.
In some of the transactions, an address parameter was sent with a none empty padding:

pragma solidity >=0.5.0;

contract TestContract {
    function testInner(address addr) public pure returns(address) {
        return addr;
    }

    function test() public view returns(address) {
        (bool success, bytes memory data) = address(this).staticcall(hex"21803c550000000000000000000022221111111111111111111111111111111111111111");
        require(success, "test error");
        address ret_addr = abi.decode(data, (address));
        return ret_addr;
    }
}

Compiling this with solc 0.5.16 and calling test() will return 0x1111111111111111111111111111111111111111
Compiling this with solc 0.8.24 and calling test() will result in revert.

We want to be able to decode the input data in python without checking for empty padding (strict=False does not apply for fixed length parameters). How can we do this?

[pacrob]

Why not just compile it with an older compiler version?

[ArielTM]

The above contract is just an example. We want to decode historic transactions to already deployed contacts

[antazoey]

I also needed this for handling data from titanoboa.
Here is my custom solution:

class ApeUnsignedIntegerDecoder(UnsignedIntegerDecoder):
    def read_data_from_stream(self, stream):
        """
        Override to pad the value instead of raise an error.
        """
        data_byte_size: int = self.data_byte_size  # type: ignore
        data = stream.read(data_byte_size)

        if len(data) != data_byte_size:
            # Pad the value (instead of raising InsufficientBytesError).
            data = validate_bytes_size(data, 32)

        return data


registry.unregister("uint")
registry.register(
    BaseEquals("uint"),
    UnsignedIntegerEncoder,
    ApeUnsignedIntegerDecoder,
    label="uint",
)

here is the code it replaces: https://github.com/ethereum/eth-abi/blob/main/eth_abi/decoding.py#L385-L394

However - realizing the real issue here is that it does not honor strict=False like another type does.