UnsupportedCapability when using function.convention(): Specified prototype declaration is a type forward which is currently unimplemented.

[arizvisa]

When function.convention() is called on functions with a specific prototype, the following exception is raised:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Users\user\AppData\Roaming\Hex-Rays\IDA Pro\base\_utils.py", line 374, in fn
    return func(*arguments, **keywords)
  File "C:\Users\user\AppData\Roaming\Hex-Rays\IDA Pro\base\_utils.py", line 292, in function.convention
    return f(*arguments, **keywords)
  File "C:\Users\user\AppData\Roaming\Hex-Rays\IDA Pro\base\function.py", line 208, in convention
    return convention(ui.current.address())
  File "C:\Users\user\AppData\Roaming\Hex-Rays\IDA Pro\base\_utils.py", line 292, in function.convention
    return f(*arguments, **keywords)
  File "C:\Users\user\AppData\Roaming\Hex-Rays\IDA Pro\base\function.py", line 222, in convention
    raise E.UnsupportedCapability(u"{:s}.convention({!r}) : Specified prototype declaration is a type forward which is currently unimplemented.".format(__name__, func))
UnsupportedCapability: function.convention(6446198110L) : Specified prototype declaration is a type forward which is currently unimplemented.

This is due to the author not quite understanding how IDA creates this calling convention. One example can likey be found in version version 20,0,0,272 or flash.ocx and is associated with the fptc function at address 0x180392d30. This function has the prototype TIMECALLBACK fptc;.

Its supval for key 0x3000 is formatted like:

Python>internal.netnode.sup.get(h(), 0x3000).encode('hex')
3d0d54494d4543414c4c4241434b00

And the entire netnode has the following supvals defined:

Python>internal.netnode.sup.repr(h())
[0] 1b : '\xff\x81\x12\xc0;\x01\x01'
[1] 1000 : '\x04\x00P\x004\x00Q\x00'
[2] 3000 : '=\rTIMECALLBACK\x00'

[arizvisa]

Pretty sure I'll need to figure out some way to evaluate this type maybe as like an idc expression or some shit..

[arizvisa]

Or it could be parse_decl from typeinf.hpp maybe...

[arizvisa]

This might've been fixed due to commit 053dbefb09876bb9aefaa1083de536675af2ba32, it'll need to be tested on a type forward.