invoke GetModuleHandle, 0, 3


works in fasm...
The assembler doesn't seem to do any parameter checking...

I also noticed one anoying thing :



invoke MessageBox, NULL, szMessage szCaption, MB_OK


As you can see, I (volontarily) forgot a comma between szMessage and szCaption... the assembler didn't said anything and the program even worked (the messagebox was longer than usual... but that is the result of an undefined behaviour imho).

Is there a way to activate parameter checking in fasm?

Thanks...

PS: Please do not take this as criticism, I'm only testing fasm strongs and flaws points before totally jumping (or not) to it...
Posted on 2002-07-23 02:04:27 by JCP
Another hidden feature to merge strings / buffers together??? :)
Posted on 2002-07-23 02:18:10 by bazik
"That is not a bug, it is a feature!" ?
Duh! :grin:
Posted on 2002-07-23 02:22:10 by JCP
Yay! :grin:
Posted on 2002-07-23 02:27:28 by bazik
solution: use a parser to check the parameters. I'll probably add this feature to my parser. ;)
Posted on 2002-07-23 02:41:19 by stryker

solution: use a parser to check the parameters. I'll probably add this feature to my parser. ;)


I hope you write your parser in FASM or plain C, so I can use it under Linux :rolleyes:
Posted on 2002-07-23 02:53:34 by bazik
Win32 FASM :) but the parser was coded without using any Win32 api calls, just pure .asm hard coded string manipulation routines.

It's complicated than first thought, due to the exhaustive win32 api. I'm still trying to implement a fast hashing routine for lookups on the api database.

Good luck to me, I hope I don't go insane looking at the masm32 includes. :grin:
Posted on 2002-07-23 03:01:08 by stryker
Your parser idea is good. ;)
IMHO, parameter checking could be done in fasm by prototypes in includes files, just as MASM does...
Posted on 2002-07-23 03:08:42 by JCP
fasm behaves this way because invoke is a macroinstruction, not built-in command, and
invoke MessageBox, NULL, szMessage szCaption, MB_OK

is simply preprocessed into:


push MB_OK
push szMessage szCaption
push NULL
call [MessageBox]

which is equal to (TASM-style pushing feature):


push MB_OK
push szMessage
push szCaption
push NULL
call [MessageBox]

as you can see forgetting the comma exchanges the message with caption. This is not a feature, this is a consequence of macro internals.
Posted on 2002-07-23 04:47:48 by Tomasz Grysztar
Thanks for your reply...

Do you plan a workaround to these "problems" ? (functions prototypes, for example)
That would suppress the "forgotten" comma problem, too...

Thanks! As for now, except this, your assembler is awesome. ;)
Posted on 2002-07-23 04:53:50 by JCP
Please NO prototypes!
I am happy to live without them! :eek:
Posted on 2002-07-23 04:57:24 by bazik
Will you still happy when you will spend some hours to look after a little stupid typo like a forgotten comma or not enough/too many parameters given to a function...
Any programmer do these mistakes, they are the most frequent and the sometimes the hardest to find. (I don't know many people that type code like Ritsuko from Evangelion that compiles the first time without any error! :grin: )

I'm not a prototype fanatic too, but I don't see another way to have efficient and flexible parameter checking. :(
Posted on 2002-07-23 05:01:10 by JCP
Personally I think that an external parser is a good solution. To be used only when is needed.

Please consider also that using RadASM or equivalent editors, you reduce syntax errors or parameter ordering/checking from the code time. Interactive way is less time consuming that a parameter checking error lists and could be more flexible.

Regards,
Posted on 2002-07-23 05:19:24 by pelaillo
Yes, but the parser will need prototypes declaration, how would it know that a function takes three or four parameters?
The parser solution just moves the prototypes outside of fasm, but you will still need them... that is only by-pass the problem imho.

One thing that made MASM popularity was his "security" regarding these things... type/parameters checking, etc... that avoided many debugging hours!

If you need fasm, you need the parser and then the include files with prototype...
One great point of fasm is that one executable can do *everything* : assembling, resource compiling and "linking"... and an external parser is somewhat the opposite (you need another tool and the assembler)...
For now, it is an acceptable solution imho, but it is only a work around that "patches" the lack of maturity of the assembler, and that it is not useless to begin to think how to add these useful features to fasm (if Tomasz agrees, of course: it is not my assembler but an user request, please consider it ;) ).
Posted on 2002-07-23 05:35:43 by JCP
OK. I agree that an external parser is annoying.

The prototypes are very well managed by RadASM :alright:, letting you to avoid making errors instead of correcting them after. They are easy customizable and easy expandable to include help for parameters and other interesting facilities.

This is a good job for the IDE, not for the assembler. Please consider also that it will depend on the platform. I code for Win32 but I want my apps running on Linux and MenuetOS with a very few rework and for this FASM is the best (in my opinion).

I disagree with considering it as a work arround or a lack of maturity of assembler. It is about the efficient way of doing things. It is like correcting orthography in-line on modern wordprocessors rather than correcting them at the end.
Posted on 2002-07-23 08:16:40 by pelaillo
I don't agree with you about the purpose of the IDE...
The IDE is not here to prevent you making mistakes but improve the productivity...

Some people here write code using the Quick Editor or the good old notepad...
RadASM is efficient with asm because it was designed for it... some others (programmer studio, ConTEXT, or even Emacs) are not.

The people who don't use assembly-efficient editors will have no defense against mistakes, except their own vigilence... which is not too much reliable, especially in big projects...

In all the compilers I have seen, it is the compiler that reports errors, and it doesn't only rely on the IDE to eventually let the user notice it (example:VC++)...

You talk about multi-platform but as far as I know there is now RadASM for Linux... what editor will you use to prevent *you* making errors? You can type your code in RadASM in windows, and compile under Linux, but, bleh, it is bypassing the problem again rather than confront to it.

Finally, the IDE only gives an hint as tooltip or anything else, but is in no way an efficient guard...

I still think that pushing too much/not enough parameters to a function is something dangerous as it can cause GPF or worse (undefined behaviour), and there is one of the best reason to why prototypes exist in others langages... catch these errors at compile/assembly time... not at the run-time.

If some people don't like prototypes, I think they may be facultative... but if *you* are self-confident enough to code without any security (especially in a langage like assembly where doing a mistake is extremely easy), have PHUN during your debugging hours or worse, when an important customer will complaint about unreliable products (and go see the concurrent)... even professionnals with dozen experience years make stupid typos...

Regards,
Posted on 2002-07-23 09:18:23 by JCP
Yes, it is a sad thing that there is no RadASM in Linux.

I am actually concerned about a plugins to use with Kate to do for Linux the same work that RadASM do for Win32 regarding param. checking.

Actually I am still working with plain text editor also in Win32 'cause I am of fixed habits, but I triyng to move to RadASM.

I easy could do GPFs in Masm if I want (I have had a lot unwanted also). :) Assembly is the best, HLL does not allow you to do interesting damages. :)

Reliable products are based in a good code style and in a well done planning but please, do not missunderstand me, I am not trying to impose nothing, I am actually expressing mi personal (and questionable) opinion. I find very interesting to hear different opinions.
Posted on 2002-07-23 09:41:14 by pelaillo
I am sure, RadASM works fine on Wine :) (www.winehq.com)
Posted on 2002-07-23 09:46:39 by bazik
For external libraries or system calls prototypes are part of defining the interface and certainly a requirement, imo. I agree with Readiosys, but would like to add that I don't want to code prototypes for all code - just where an interface boundary is (or in the rare case the code doesn't outline the interface for a routine). Additionally, if the assembler provided this kind of 'help', it should be able to turn it off or override it (as MASM allows). Assemblers should provide the flexiblity to do whatever I want by default, and then have the power to create high level assemble-time or run-time structures to speed coding where selected.
Posted on 2002-07-23 09:51:51 by bitRAKE
I don't want to put any HLL stuff into fasm, and I won't do that. You can customize the syntax using the macroinstructions (will be a bit enchanced in 1.40, and well documented in the new docs I'm working on currently), but if you need something more, you should use external tools. Like the C compilers generating assembly sources you can have some kind of HLL assembly compiler generating sources for fasm, why not?
I one write something of that kind and it's good I can promote it on my website.
Posted on 2002-07-23 10:06:57 by Tomasz Grysztar