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...
Another hidden feature to merge strings / buffers together??? :)
"That is not a bug, it is a feature!" ?
Duh! :grin:
Duh! :grin:
Yay! :grin:
solution: use a parser to check the parameters. I'll probably add this feature to my parser. ;)
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:
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:
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:
Your parser idea is good. ;)
IMHO, parameter checking could be done in fasm by prototypes in includes files, just as MASM does...
IMHO, parameter checking could be done in fasm by prototypes in includes files, just as MASM does...
fasm behaves this way because invoke is a macroinstruction, not built-in command, and
is simply preprocessed into:
which is equal to (TASM-style pushing feature):
as you can see forgetting the comma exchanges the message with caption. This is not a feature, this is a consequence of macro internals.
invoke MessageBox, NULL, szMessage szCaption, MB_OKis 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.
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. ;)
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. ;)
Please NO prototypes!
I am happy to live without them! :eek:
I am happy to live without them! :eek:
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. :(
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. :(
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,
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,
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 ;) ).
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 ;) ).
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.
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.
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,
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,
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.
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.
I am sure, RadASM works fine on Wine :) (www.winehq.com)
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.
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.
I one write something of that kind and it's good I can promote it on my website.