Hello,

I have been wondering if on error fasm could show the name of the symbol that has actually caused the problem (i.e. in display edit box). I know it may be not very nessecary, as nobody was complaining till now but last time I had error on line like this:

where:
>MY_PROC was not defined in module from which it was called (lets call that module: ext_module)
>I had 'win32a.inc' in ext_module
when include directive for ext_module was at the beginning of my program (no sections were used) program compiled successfully, but after there was need to have the code of ext_module at the end of the program i was gettin error.
And to be honest with you, I must say that it took me some time to realise that it isnt that fasm doesnt recognize MY_PROC, arg1 or arg2 but its that after moving the include 'ext_module' i have also moved include 'win32a.inc' at the same time (which I missed)- so fasm didn't know the stdcall macro yet.

I think that such feature could help programmers new in fasm/assembly language - to correct their errors, especially when they are in lines where there is more than one posible reason of the error.

Id like to hear some opinions about it, so we can see if thats a good idea or rather not, thx

well, FASMW version does show the problematic instruction, but command line versions doesn't. I agree this sucks...

I think that fasm should be more specific at which thing it considers as undefined.

Tell me how much time takes you to fix the attached code.

BTW, I use FASMW and even with it this code took me a lot of time to figure out what was wrong.

[edit]Well, actually looking at it again looks very simple to know what is the problem but for some reason it was very hard for me at that time [/edit]

Loco: only problem I had was missing definition of MAX_PATH

Nop, the problem is that it was defined twice. I remember now why it was hard to figure out

So, the good adition could be some warning, instead of just saying "undefined symbol", say "symbol out of reach" when it is defined but it can't be forward referenced.

The fix in this particular code is just erasing MAX_PATH at this code fragment

And will compile just fine because fasm package already defines that constant somewhere in the include files.

hehe so it looks like its not only me who would like more specific informations on error lines.
Lets see if Tomasz will give it to us (but still, id rather like to see debug symbols support first there lol) anyways i still really appreciate all the work Tomasz put into fasm :]

..::FASM RuLeS::..

this is good idea. i think this could be easily patched in FASM. I will try to add it to my patched FASM version

Wow, that didn't take you long, Tomasz. Thanks a lot