I am trying to get the byte size of all operands in a given instruction from IDA Pro. At first I tried using GetOperandValue(ea,n) to see how large the value was and calculate how many bytes were necessary to store that value, but it doesn't return leading zeros, which means that it doesn't work.

Now I am trying to use OpHex(ea,n) to get the answer, but it's just returning True (as do OpDecimal, OpBinary, and OpOctal).

How can I find the number of bytes used for operands of a particular instruction and why is OpHex returning true?

Edit: My current solution works, but I would still like one that is more technically correct and bulletproof. Right now I am just using GetOperandValue(ea, op) to get both operands for all instructions (even if they have neither or only one) and then checking to make sure the operand value is greater than FF. If It's greater than FF I just assume it is an address, which in this case is four bytes. If both operands meet this condition, I assign the size to be eight bytes.

This works for the moment, but will encounter difficulties in eventual moves to other architectures (right now I'm just working with x86-64).

  • 1
    Do you mean a value in an opcode instruction like mov or the size of a data structure to which some pointer is pointing? – pudi Nov 8 at 6:10
  • The size of the operand(s) in an opcode instruction, not the size to which it is pointing. To recreate the relocation I need to know how many bytes to overwrite with addresses. – theTheodidact Nov 13 at 17:36

Are You Loooking for some thing like

Message("%s\n" , GetCurrentLine());
Message("%x\n" , ItemSize(ScreenEA()));

this will give results as below

.text:010328BB 56                            push    esi
.text:010328BC BE 10 42 05 01                mov     esi, offset unk_1054210
.text:010328C1                               cmp     byte_1054309, bl
.text:010328C1 38 1D 09 43 05 01             cmp     byte_1054309, bl
  • 1
    Seems the inquirer is only interested in the size of the operands, not the instructions overall. But this is close. – 0xC0000022L Nov 15 at 21:24
  • Yes, @0xC0000022L is correct. – theTheodidact Nov 16 at 18:42

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.