Hi,

I don't even know if this is a bug, but I am having trouble with the code below:



Is this a bug? Is there any way (besides preposing a dot before Aloha) to bypass this feature/bug?

what are you expecting and what are you getting?

If you are talking about refering to .teste instead of Aloha.teste, then you might want to try the "local" keyword. However, I am not sure if it works outside of a macro

comrade: it doesn't, there's no "local" for virtual.
but you shouldn't declare virtual inside some code namespace, place it somwhere where it doesn't matter.

Try this:

that's not a bug.. label define inside virtual has the same rules outside it.. rev's solution should work.

I was thinking of something like:

xpto: ;//This would be my function

mov eax , .ret

;//In here, I would use some macros for parameters and local variables, using virtual
virtual at 0
Aloha:
.data1 dd ?
end virtual

.ret:
ret[/quote][/code]

What does the '..' do to the label definition inside the virtual declaration?

".." means that label won't overwrite current namespace:

i still don't know what you want. are you sure you understand "virtual" right?

Yes, but, since virtual stablishes a new section, it's labels should not 'break' the proc's labels...
I am inside a proc, named MyProc ... I created a macro that uses virtual to create local labels (Yes, I know that it has already been done, but I wanted to create use only code I could be sure to understand), and they use a pure label and the dot notation internally...
I imagined that, since the label inside the virtual isn't really there (it is outside the proc's address), it should not cut the proc's label mechanism...
Have I been clear enough?

The "." mechanism (like "@@", too) is processed by the parser, before the assembly stage - the "virtual" and other such directives have no meaning yet at that time. The parser just attaches name beginning with dot to the last "global label" - that is the one not starting with dot - it met to be defined. At the assembly stage it may become modified in many different ways, but the parsing is already done. For example:

after parsing becomes something like:

and even though when the assembler processes it "Alpha" itself never actually gets defined, the parsing has already been done this way.

This mechanism of "locals" was taken from NASM for its simplicity; for "true" locals you might look for some macro solutions (like the "proc" macro package for Win32, or something like http://board.flatassembler.net/topic.php?t=3744)

Thanks everybody.