Hello, asking again ...

is there a way to limit names' scope within a source file? (not talking about local names)

the problem is the following:
i am building a custom binary image from several segments using virtual address spaces containing loaded (file) and compiled data, using load/store.
It happens that i need some functions to be physically present in multiple segments, so i decided to define macros for these to quickly 'instantiate' them in the virtual segments, but the global function names conflict with eachother within the different virtual blocks. I've been scratching my head for some time now about how to avoid these conflicts without having to deal with scrambled function names within the different segments.
Any ideas welcomed,
thank you,
pepe

fasm 2 and its fasmg engine have NAMESPACE / END NAMESPACE directives for this purpose. It is in fact one of the cornerstones of fasmg's design and what pushed me to start developing it.

yes, i kind of saw it from the corner of my eyes, but i am using fasmarmw, which is built on v1 afaik... :s

Moving to non-x86 forum. The post doesn't appear to be anything Windows specific

Perhaps an option is to use struc instad of macro and add a leading dot to the label names.

well, the problem is not architecture specific, it looks like it is because it can be worked around in fasm2 easily, but this is not what fasmarm is built on. The problem is specific to fasm 1 regardless of the architecture. That's why it was posted in the main thread.
(And FASM is not windows specific, either)

2: i was experimenting with struc as well, but came up with nothing useful (might be my lack of understanding as well). Gonna give your example a try. I dropped the whole idea for now as it seems to be taking more efforts than it deserves in my current project, so just put my functions with different name prefixes in the segments requiring them. Not very nice but that's it.

thank you ,
pepe

You posted to Windows originally. But no matter it can also live in Main.

did i? oops, yeah, that was a mistake then... sorry.