Author Topic: Questions about operand size specification in NASM  (Read 9188 times)

Offline ben321

  • Full Member
  • **
  • Posts: 185
Questions about operand size specification in NASM
« on: October 16, 2015, 07:22:00 PM »
Normally you need to specify operand size (or you'll get an error) such as with:
PUSH [MyVar]

It should be instead:
PUSH dword [MyVar]

or it should be:
PUSH word [MyVar]

But with CALL it doesn't require that for some reason. Even though you can have either a 32bit relative address, or 16bit relative address (which introduces ambiguity) NASM does not give me an error when I use call like this:
CALL [VarThatHoldsAddressToJumpTo]

From my understanding of NASM not permitting any ambiguity, the above line of code should produce an error, requiring me to change it to:
CALL dword [VarThatHoldsAddressToJumpTo]

or change it to:
CALL word [VarThatHoldsAddressToJumpTo]


Is this a bug in NASM, that it isn't giving me an error when CALL is used without an operand size indicator? Or am I misunderstanding something about how NASM is supposed to work?

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: Questions about operand size specification in NASM
« Reply #1 on: October 17, 2015, 04:30:45 AM »
AFAIK, "call [mem]" defaults to the current bitness. You can override it - you probably don't want to - or confirm the size if you think it makes it clearer...

At one time "push 0" required a size specifier, but it was changed to default to current bitness - I don't know why "push [mem]" doesn't do it but it still requires the size specifier.

Best,
Frank