Is this an assembler bug ?

[RuiLoureiro]

Hi
     Do you know why it happens ?
     Hutch, where is the problem ?
     I have a lot of LOCAL IndexLst but i dont get any error message.
     Why ? If it is LOCAL it is valid only inside that particular proc ( should be !).
     So, what is the problem or where is it ?
     Thanks   :t
     

Microsoft (R) Macro Assembler Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

Assembling: C:\calcula_78\Calcula68.asm

***********
ASCII build
***********
C:\calcula_78\Rcl05.inc(891) : error A2005:symbol redefinition : AuxBuffer
_
Assembly Error
Prima qualquer tecla para continuar . . .

«««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
AnalyseSymbolicSingleType   proc        pRclStr:DWORD, pVarType:DWORD
                            LOCAL       AuxBuffer[$TOTALofSTACKBUFFER128]:BYTE    <<<<<<- line 891 <<<<<<<<
                            LOCAL       IndexLst:DWORD, IndexFirst:DWORD
                           
                            push        ecx
                            push        esi
                            push        edi
                           
                            ;-------------------------------------------
                            ;                 AuxBuffer
                            ;-------------------------------------------
                            ALIGNLOCALPOINTERedi  AuxBuffer, $LENofSTACKBUFFER128
                            ; ALIGNLOCALPOINTERedi is a macro to align the address in edi by 16
            ...

                _exit:      pop         edi
                            pop         esi
                            pop         ecx
                            ret
AnalyseSymbolicSingleType   endp
«««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

[jj2007]

Check for a global variable with the same name.

Code Select Expand

include \masm32\include\masm32rt.inc

.data
AuxBufferG db 1000 dup(?) ; call it AuxBufferG, and it's OK

.code
MyTest1 proc
Local AuxBuffer[80]:BYTE ; no problem ...
  ret
MyTest1 endp

MyTest2 proc
Local AuxBuffer[80]:BYTE ; ... to use it locally ...
  ret
MyTest2 endp

HelloWorld macro
LOCAL AuxBuffer ; ... or in a macro
  AuxBuffer=1
  print "hello world"
ENDM 

start:
  HelloWorld
  exit

end start

[hutch--]

Change "AuxBuffer" to "Aux_Buffer" and see if it makes any difference. If not the problem is elsewhere.

[RuiLoureiro]

Change "AuxBuffer" to "Aux_Buffer" and see if it makes any difference. If not the problem is elsewhere.

Hi Hutch, thanks
Yes if i change the name it works correctly. But my problem is to understand why it happens.
And Jochen gave the correct answer.
note: i dont like aaa_bbb names. Unfortunately i violated my own rules about names of labels and i got
this problem or i found out the bug.
See you  :t
:icon14:

[RuiLoureiro]

Check for a global variable with the same name.

Code Select Expand

include \masm32\include\masm32rt.inc

.data
AuxBufferG   db 1000 dup(?)   ; call it AuxBufferG, and it's OK

.code
MyTest1 proc
Local AuxBuffer[80]:BYTE      ; no problem ...
  ret
MyTest1 endp

MyTest2 proc
Local AuxBuffer[80]:BYTE      ; ... to use it locally ...
  ret
MyTest2 endp

HelloWorld macro
LOCAL AuxBuffer      ; ... or in a macro
  AuxBuffer=1
  print "hello world"
ENDM 

start:
  HelloWorld
  exit

end start

Hi Jochen, yes i have a global with the same name and it is the bug.

My own rule to write labels is to start with underscore: _AuxBuffer, etc.
But inside macros or LOCAL variables i dont use underscore: AuxBuffer.
Unfortunately i violate that rule and i found out the bug.
Thanks Jochen
See you  :t

[jj2007]

You are welcome :icon14:

[hutch--]

You get used to these problems with both assemblers and compilers. Having used a BASIC compiler for some of my work for years, this particular one is case insensitive and as such uses a large number of reserve words so one of the first things you do is change the variable name to see if that is the problem. Generally MASM in either 32 or 64 bit has less than helpful error messages (screens of chyte streaming past) so you learn a few tricks around it, one is the keep track of your naming system for variables.

Glad you solved the problem.

[RuiLoureiro]

You are welcome :icon14:

Very nice to see you here Jochen :t
:icon14:
By the way, the answer to my question is: YES it is !
And so, i was righ when i established that set of rules many years ago
to write labels in assembly: start with underscore if it is not inside macros
or it is not a LOCAL variable. It seems that it never fails.

[RuiLoureiro]

You get used to these problems with both assemblers and compilers. Having used a BASIC compiler for some of my work for years, this particular one is case insensitive and as such uses a large number of reserve words so one of the first things you do is change the variable name to see if that is the problem. Generally MASM in either 32 or 64 bit has less than helpful error messages (screens of chyte streaming past) so you learn a few tricks around it, one is the keep track of your naming system for variables.

Glad you solved the problem.

Thanks and glad to see you here.
Yes i solved the problem and i understood it.
I want to say to you that i am writing assembly and
you are guilt for that. 
Thanks for all, Hutch-- :t

[RuiLoureiro]

Hi
    I am thinking now that my question may be not a bug. It seems that the macro assember
assumes that we cannot choose a local name equal to a global name (defined in .DATA or .DATA?).
Do you know the rules, Jochen ?
In any case think about the label "_exit" inside a procedure. We may write _exit in
all procedures because it is particular or LOCAL label: it is valid only inside that
procedure. Following this fact, any other label defined using the word LOCAL would be
considered as a local, so an exception to the general rule. But not, the macro assembler
refuse it.
That's all
Good luck  :t
note: i have another case where the defined LOCAL variables dont work
correctly. When the procedure is called it closes the program (TheCalculator) before starting
my first instruction push ebx, etc. I replaced only all locals Name[nbytes]:BYTE
by global names defined in .DATA? and all works correctly. By the way, i replaced
also by local names defined by me using this schema (it works correctly):
ProcA   proc              ; prolog and epilog none
            push ebp
            sub   esp, lenstackbuffer
            mov  ebp, esp
            ; now push ebx, esi, edi, ,,,
...
            ; now pop ...,edi, esi, ebx
            add   esp, lenstackbuffer
            pop   ebp
            ret     4*N
ProcA   endp

stk0_varA     = 0                               ; here i use names aaa_bbb !!! 
stk0_varB     = stak0_varA + lenofA
...
stk0_varK     = stk0_varK-1 + lenofK-1
where the adresses are defined by
lea       esi, [ebp+stk0_varK] (this is an example).