Warning A4238: Text macro used prior to definition: lParam

[jj2007]

I have massive problems with a UAsm bug. It manifests itself with
- Warning A4238: Text macro used prior to definition: lParam
- Error A2210: Syntax error: r8

Apparently, this macro is involved:

Code Select Expand

jbSetArgs MACRO
Local is, arg$, argS, tmp$ ; OPT_Errline 0
  While _RegCt
arg$ CATSTR <_R>, %_RegCt, <$>
; % echo arg$
is=0
pos=0
% forc c1$, <arg$>
pos=pos+1
ifidn <c1$>, <:>
is=pos
; echo OK
endif
; echo c1$
endm
if is
argS SUBSTR arg$, is+1
arg$ SUBSTR arg$, 1, is-1
; % echo +++ arg$ +++
else
argS equ SIZE_P
; % echo ### arg$ ###
endif
_RegCt=_RegCt-1
if argS eq SIZE_P
arg$ CATSTR arg$, < equ >, @SubStr(<rcx#rdx#r8 #r9 #>, 1+4*_RegCt, 3)
else
arg$ CATSTR arg$, < equ >, @SubStr(<ecx#edx#r8d#r9d#>, 1+4*_RegCt, 3)
endif
tmp$ CATSTR <SetArgs, line >, %@Line, <: args=>, arg$
% echo tmp$ ****************** ; OxPT_Assembler uasm64Dec8 ; lParam equ r9 problem
; OxPT_Assembler ML ; works fine
arg$
  Endm
ENDM

The echo tmp$ is e.g. lParam equ r9 or wParam equ r8, which is correct and intended. But it chokes then with Syntax error: r8.

The bug creeps up in UAsm versions after Dec 8, 2017. Earlier versions are fine.

[habran]

Hi JJ
Can you give me a short example where you use that macro.
I can not step through the macro to see what is going on, I need some proggy to do that

[jj2007]

Ehm... a short example? Difficult. But I have prepared an archive here. Read the Important.txt

There is a line OxPT_Assembler uasm64Dec8

If you remove the x, it becomes a valid OPT_ and F6 will launch \Masm32\bin\uasm64Dec8.exe - the last one that works.
In case you don't have that version, it's here.

The Error A2210: Syntax error: r8 happens in DualWin.inc, but the line number indicated is bogus (which is a separate problem, I know). I suspect that some structures containing lParam or wParam do not work properly.

There is a file SkelDualGui.asc in the archive; open with RichMasm, hit F6. This works fine, as most of my other templates. The error happens reproducible in the \Masm32\MasmBasic\Res\DualBasicSource.asc file, but I've seen it also in other sources. The problem could be a scope problem: lParam and wParam get defined some place, as equates, and in a completely different context such as the include file DualWin.inc, the error pops up because lParam and wParam are used in structures.

P.S.: In line 9 of the source is an OPT_64 1. Change to OPT_64 0 to see the 32-bit version, which assembles fine because it doesn't use that macro.

[habran]

Hmmm, it sounds complicated
It wouldn't be if I could reproduce the bug. I'll see what I can do. ::)

[aw27]

I have massive problems with a UAsm bug

If it worked until a certain point and ceased to work after that does not forcibly imply to be a bug.
Since nobody in this planet understands the pseudo code you invented and you simply zipped some enigmatic crap and pushed it forward I don't really know how you expect to be helped. 

[jj2007]

José, why don't you simply shut up, instead of boasting with your incompetence?

The same identical code works fine with MASM, and UAsm is a MASM clone. Besides, it worked before Dec 8, 2017, so something was introduced then that damaged the 100% compatibility claim. I know very well that chasing this bug is not easy, since I've invested already a lot of time in it.

[aw27]

Only in your insane mind UAsm is a MASM clone (mentioning it is an obvious way to pass a demerit message). What UAsm, as well as JWASM have done, is keep a high degree of compatibility with MASM.
This is a common strategy in DOS/Windows assemblers, as old as I can remember, since TASM and A86 times. Only the NASM family of assemblers depart from this paradigm, probably because they could not care less about Windowz.
So, what you have to do, in my opinion, is produce a decent bug proof of concept instead of using every opportunity to spam your pseudo code.

[hutch--]

There really is a problem dumping a large body of information that no-one else is going to wade through, if a bug has been found, it needs to be put in a test piece that can be built by others who use the assembler to try and find out what if anything is wrong. With MASM macros which I have used since the MS-DOS MASM 6.0 days, you never ever trust them to be the same from one iteration of the assembler to another. In Win32 and much later Win64 you start from scratch and design your macros making sure they work correctly with the assembler that is being used.

JWASM was never MASM compatible, it was similar but never built any of my larger applications, I suggest that this is a similar situation with UASM and Nidud's ASMC. Now when it comes to bugs, the pre-processor in MASM is full of them and it has been that way since MASM 6.0 and one of the problems with building a MASM compatible assembler is duplicating MASM's bugs, something that is generally not wise to do.

[jj2007]

Hmmm, it sounds complicated
It wouldn't be if I could reproduce the bug. I'll see what I can do. ::)

Thanks a lot. In the meantime, I could confirm that the error happens inside structures in DualWin.inc:
MSG STRUCT
  hwnd      SIZE_P      ?
  message   DWORD      ?
  wParam    SIZE_P      ?
  lParam    SIZE_P      ?
  time      DWORD      ?
  pt        POINT      <>
MSG ENDS

The sequence of echos and error messages (the first one produced by tmp$ CATSTR <SetArgs, line >, %@Line, <: args=>, arg$, see above, SetArgs MACRO):

Code Select Expand

SetArgs, line 1885: args=lParam equ r9 
...
Warning A4238: Text macro used prior to definition: lParam
MacroLoop(29): iteration 1: Macro called from
  jbSetArgs(32)[Tmp_File.asm]: Macro called from
   JBasicProlog(64)
...
\Masm32\MasmBasic\Res\DualWin.inc(7647) : Error A2210: Syntax error: r9

With a global lParam equ eax, any structure containing lParam chokes; this is OK and happens with Masm and UAsm alike. So I suspected that the problem was with local args:

Code Select Expand

include \masm32\include\masm32rt.inc

.code
somecallback proc hWnd, wParam, lParam
  ret
somecallback endp

bar STRUCT
  lParam dd ?
  wParam dd ?
bar ENDS

foo bar <123, 456>
start:

  inkey str$(foo.lParam)
  exit

end start

Works fine with Masm and UAsm, though. But I have a suspicion: In another context, I discovered that using a macro like Str$() etc in a PROLOG macro produces weird behaviour (in Masm and UAsm). What happens is that Str$() gets declared twice, inside the PROLOG and once more outside. And in the second instance of creating Str$(), any ifndef varname inside the macro fails because it thinks the var has not been declared yet.