sad-dev

I just noticed there's this option  and I assume "TMode=0" or "TMode=1" is the intended usage here. Would still like to know if (I assume not) the model can...

Perhaps some ``Action`` that calls ``ClangTypeToken.getDataType().getBaseDataType()`` or similar to fill the clipboard?

Another problem with the x86-16 sleigh is that it implicitly assumes (in ``currentCS`` and ``rel16``) that the segment register is a multiple of ``0x1000`` when resolving references of all kinds...

I have not touched it in a while, but from memory the failure pattern I ran into was something like this - both ``1000:F000`` and ``1F00:0000`` correspond to the same...

Apologies for the late reply. I have been playing around a bit more (including with the VT api) to get a better understanding of how I can/would like to use...

I dabbled with modifying the decompiler (``Varnode::isBooleanValue``, ``ActionFuncLink::funcLinkOutput`` and ``FuncCallSpecs::commitNewOutputs``) but with little success. For example, I removed the following check in ``ActionFuncLink::funcLinkOutput`` ``` ProtoParameter *outparam = fc->getOutput(); Datatype *outtype...

OK, noted. I will give the ``aggressivetrim`` suggestion a go too. I have some ideas for a different datatype, specifically, an int4 that displays like a string (useful for functions...

``ParameterDB.equals`` should probably also be fixed - it appears that ``foo.getParameter(0).equals(bar.getParameter(0))`` can return ``true`` due to ``VariableDB.isEquivalent`` not checking for equality of functions ``` @Override public boolean isEquivalent(Variable otherVar) {...

To the best of my knowledge, neither a ``List`` or ``HashSet`` of ``Variable`` is used in a way that would change as a result of this e.g. ``.contains``

> I don't think this PR change can be accepted since your use case is not supported (i.e., mixing params from multiple functions into a set) and changes would break...