2

Consider this asm code which passes [myConst] to printf

.386
.model      flat, stdcall
option      casemap :none
includelib  libcmt.lib
includelib  legacy_stdio_definitions.lib
printf      PROTO NEAR C,:DWORD,:DWORD

.const
    myConst EQU 4096

.data
    HelloWorld db "Hello World! %d", 0

.code

main PROC NEAR C 
    invoke  printf,ADDR HelloWorld,[myConst]
    ret
main ENDP

END

Assembling with Microsoft (R) Macro Assembler Version 14.16.27034.0 from VS2015, notice [myConst] is assembled as push 1000h

lea32!main:
00ee1000 6800100000      push    1000h
00ee1005 6800a0f300      push    offset lea32!HelloWorld (00f3a000)
00ee100a e8561d0000      call    lea32!printf (00ee2d65)
00ee100f 83c408          add     esp,8
00ee1012 c3              ret

and running the program correctly outputs

Hello World! 4096

But, assembling with Microsoft (R) Macro Assembler Version 14.29.30148.0 from VS2019, notice [myConst] is assembled as push dword ptr ds:[1000h]

lea32!main:
00e51000 ff3500100000    push    dword ptr ds:[1000h] ds:002b:00001000=????????
00e51006 6800a0ea00      push    offset lea32!HelloWorld (00eaa000)
00e5100b e8651d0000      call    lea32!printf (00e52d75)
00e51010 83c408          add     esp,8
00e51013 c3              ret

and running the program crashes on an access violation

(4920.8f64): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=0089b770 ebx=01164000 ecx=00000000 edx=ee80b838 esi=014270b0 edi=014290f0 eip=00841000 esp=012ff7e0 ebp=012ff824 iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b
efl=00010206 lea32!main: 00841000 ff3500100000 push dword ptr ds:[1000h] ds:002b:00001000=????????

Question

Did Microsoft introduce a bug going forward with VS2019?

Does Microsoft have a change history for MASM?

(The obvious fix is to remove the []'s around myConst)

Michael Petch
  • 46,082
  • 8
  • 107
  • 198
vengy
  • 1,548
  • 10
  • 18
  • 2
    If you don't want it to be treated as a memory operand, don't put `[]` around it. I always considered it a ridiculously bad design that `[]` were ignored around constants, as in [Confusing brackets in MASM32](https://stackoverflow.com/q/25129743) . IMO, the old behaviour was a bug and it's good that it's fixed. But my opinion isn't worth much because I've always thought MASM syntax was dumb in general compared to NASM. – Peter Cordes Mar 10 '23 at 02:04
  • But to some degree, changing poor syntax-design choices after the fact is not great either; it can break people's code for little future benefit. New code can only start leaving out the `dword ptr` in `dword ptr [100]` absolute address loads if you don't care about it working the way you intend on old MASM versions. At least it's possible to write code that works with old or new MASM, unlike the unfixable [AT&T syntax bug](//sourceware.org/binutils/docs/as/i386_002dBugs.html) where GAS chose to be bug-compatible with AT&T's Unix assembler for non-commutative x87 instructions with 2 regs. – Peter Cordes Mar 10 '23 at 12:29

0 Answers0