Argument names in procedure

[bEaST2k]

Hi there,

just arrived at the masm forum and a hello @all  :U.

Maybe some of the masm-gurus here can answer this question:
Why masm-compiler is complaining about variable redefinition in this case:

Code Select Expand


[pseudo]
PROTO Foo DWORD

.data
szWord db "Hello masm",0

.code
start:
      invoke Foo,addr szWord
end start

Foo proc szWord:DWORD
     ; ....
Foo enp


Is there any way to bypass this (without renaming the szWord variable nor the szWord:DWORD parameter  :wink)?

Regard,
Fabian

[Vortex]

Hi Fabian,

Welcome to the forum.

To assemble properly your code, you must to rename one of those szWord statements to avoid symbol redefinition and conflicting parameter definition.

[P1]

bEaST2k ,

Welcome to MASMforum!       :U

Read around the different areas and get a feel for the place.         :dance:

Read the help files and tutorials of MASM32.   It's best, if you download the most recent MASM32 package and install it. 

'Search' & Google are your friends for programming.  Then ask your questions.     

Technically, it's a pointer.  Foo proc pszWord:DWORD  Foo on you !   :green2

Regards,  P1   :8)

[Grincheux]

I suggest :

Foo PROC lpszWord:LPSTR
     ; ....
Foo enp

Because the parameter is a pointer not a string.

[Vortex]

Grincheux, LPSTR is defined as DWORD in windows.inc :

Code Select Expand

LPSTR typedef DWORD

[Grincheux]

YES but it is easier to understand.

[Vortex]

YES but it is easier to understand.

Grincheux, one of the most powerfull features of asm is that you assume that all those LPSTR and similar statements are equal to DWORD This approach eliminates the need to remember various C based variable types during coding as there is no type casting in asm. In most of the cases, pointers are DWORD values.

[Grincheux]

and characters are numbers...

[gabor]

...and really talented ASM coders are aliens.  :green

[hutch--]

Administration is tolerant of Martians as we may have a few but we may draw the line on anyone from Venus unless they cool down a bit.

[BogdanOntanu]

Ooops,
Indeed I am an alien on Earth... how did you found out?
But I look humman, I do all things like hummans do, I even die like hummans do...

Only because  I do programm huge applications in 32bits ASM... <--- did THAT simple fact blow my cover?

Now you only have to be carefull with GLOBAL variable names (same as in any programming language)

However multiple procedures can use the same name for variables, arguments or labels.
For example in TASM style:

Code Select Expand


My_Proc1 PROC
ARG: @@wnd_handle:dword, @@x1:dword,@@y1:dword
LOCAL @@tmp_x1:dword

... some code ...
@@loop_on_x:
...some code...
inc [@@x1]
dec ecx
jnz @@loop_on_x

ret
ENDP

My_Proc2 PROC
ARG @@parent_handle:dword, @@wnd_handle:dword, @@x1:dword
LOCAL @@tmp_x1:dword

...

@@loop_on_x:
    ...some code...
inc [@@x1]
dec ecx
jnz @@loop_on_x
ret
ENDP


Argument names will not colide inside PROCEDURES because they are SCOPED LOCAL to each procedure
Neither will LABELS not LOCAL variables...

So --> watch your GLOBALS :)

[bEaST2k]

Sorry for the late reply, you've better don't ask for the reason  :red...

Code Select Expand


My_Proc1 PROC
ARG: @@wnd_handle:dword, @@x1:dword,@@y1:dword
LOCAL @@tmp_x1:dword

My_Proc2 PROC
ARG @@parent_handle:dword, @@wnd_handle:dword, @@x1:dword
LOCAL @@tmp_x1:dword



Argument names will not colide inside PROCEDURES because they are SCOPED LOCAL to each procedure
Neither will LABELS not LOCAL variables...

So --> watch your GLOBALS :)

This  @@-Stuff came to my mind last week too. But come on, it's everything else then nice code  :wink!
But anyway, it's apparently the only way to get out of the redefinition...

Thanks for all the answers and especially for the warm reception  :U!