Ok, I'm going completely out of my mind here...

I have found what appears to be a completely crazy bug in MASM (if it's not in MASM, it's either in bitRAKE's macro, or in my brain (most likely :)), but I can't find anything wrong with any of them ;)).


Here follows a simple example, demonstrating the bug:

I'm using the following simple macro by bitRAKE (taken from the "sniplets" box of RadASM):



@ArgI MACRO index:REQ, args:VARARG
;; Macro function returns an argument specified by number from a VARARG list.
;; Params: index - one-based number of the argument to be returned
;; args - argument list
LOCAL arg,y,yStr
y = 0
FOR arg,<&args>
y = y + 1
IF y EQ index
yStr TEXTEQU <arg>
EXITM ;; Exit FOR loop
ENDIF
ENDM
EXITM yStr
ENDM


I also have made the following very simple macro myself, that reproduces the bug:



global_list TEXTEQU <first_entry> ; This is a global comma-separated list,
; initialized with one string.

; This macro adds the second parameter to the
; global comma-separated list
ADD_SECOND_ARG_TO_LIST MACRO new_strings:VARARG
% ECHO List contents (1): global_list
current_entry TEXTEQU @ArgI(2, new_strings) ; Saving second arg in variable
% ECHO List contents (2): global_list
% ECHO Added string: current_entry
global_list CATSTR global_list, <, current_entry> ; Adding string to list
% ECHO List contents (3): global_list
ENDM


It really only contains 2 lines, the rest is just debug-text that will help showing the bug.


Finally, the very simple program using this macro looks like this:



ECHO ### Call 1 ###
ADD_SECOND_ARG_TO_LIST <ignored_string>, <added_string_1>
ECHO ### Call 2 ###
ADD_SECOND_ARG_TO_LIST <ignored_string>, <added_string_2>



When compiling this, the expected compiler debug output should, according to my understanding, be the following:



### Call 1 ###
List contents (1): first_entry
List contents (2): first_entry
Added string: added_string_1
List contents (3): first_entry, added_string_1
### Call 2 ###
List contents (1): first_entry, added_string_1
List contents (2): first_entry, added_string_1
Added string: added_string_2
List contents (3): first_entry, added_string_1, added_string_2


But instead I get this:



### Call 1 ###
List contents (1): first_entry
List contents (2): first_entry
Added string: added_string_1
List contents (3): first_entry, added_string_1
### Call 2 ###
List contents (1): first_entry, added_string_1
List contents (2): first_entry, added_string_2 <--- What the f***?!?
Added string: added_string_2
List contents (3): first_entry, added_string_2, added_string_2 <---


After it has extracted the second argument from the macro VARARG parameter with the @ArgI macro, the contents of the global list has all of a sudden changed from <first_entry, added_string_1> to <first_entry, added_string_2>, and it was not even referenced in that line!?! This in turn messes up the final list to be <first_entry, added_string_2, added_string_2> instead of the desired <first_entry, added_string_1, added_string_2>. :(


So, does anyone here have the slightest clue about why this happens? Is this a bug in MASM, or is it just me being completely blind and stupid? Does it behave differently in anyone else's MASM-compiler here?

Any ideas whatsoever would be greatly appreciated.

Thanks!
Posted on 2003-01-13 17:12:24 by dELTA
Originally posted by dELTA


global_list TEXTEQU <first_entry> ; This is a global comma-separated list,
; initialized with one string.

; This macro adds the second parameter to the
; global comma-separated list
ADD_SECOND_ARG_TO_LIST MACRO new_strings:VARARG
% ECHO List contents (1): global_list
current_entry TEXTEQU @ArgI(2, new_strings) ; Saving second arg in variable
% ECHO List contents (2): global_list
% ECHO Added string: current_entry
global_list CATSTR global_list, [color=red][b]<, >, current_entry[/b][/color] ; Adding string to list
% ECHO List contents (3): global_list
ENDM


It really only contains 2 lines, the rest is just debug-text that will help showing the bug.


Finally, the very simple program using this macro looks like this:



ECHO ### Call 1 ###
ADD_SECOND_ARG_TO_LIST <ignored_string>, <added_string_1>
ECHO ### Call 2 ###
ADD_SECOND_ARG_TO_LIST <ignored_string>, <added_string_2>


... (the final output)...

[color=red]Microsoft (R) Macro Assembler Version 6.14.8444

Copyright (C) Microsoft Corp 1981-1997. All rights reserved.

Assembling: D:\masm32\_ACTIVE\elec\elec.asm
### Call 1 ###
List contents (1): first_entry
List contents (2): first_entry
Added string: added_string_1
List contents (3): first_entry, added_string_1
### Call 2 ###
List contents (1): first_entry, added_string_1
List contents (2): first_entry, added_string_1
Added string: added_string_2
List contents (3): first_entry, added_string_1, added_string_2
Microsoft (R) Incremental Linker Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.[/color]


Never doubt the machine ;)
(( One day i swore that Microchip blew a batch of microchips and i had boughten a completely bad set of PIC chips.. of course i later realized it was just me, high on solder fumes and lack of sleep ;) ))

:alright:
NaN
Posted on 2003-01-13 19:34:42 by NaN
Thanks NaN! :)

Ha ha, holy crap the kind of effects you can get with code that can perform string operations on its own variable names during execution, and has scope-less delay of symbol evaluation. :tongue:

I have to admit it took a moment to understand why I got that effect even after you pointed out the exact erroneous line. :)

To anyone reading this, for a good laugh I can really recommend you to try to understand the exact chain of events that followed from my little typo, and finally resulted in the behavior described in my original post. :alright:

Thanks again NaN!
Posted on 2003-01-13 20:24:12 by dELTA
Glad you got it, cause i didnt want to explain that one ;) . Heck your description of the problem alone is a mouth-full ;) :
Ha ha, holy crap the kind of effects you can get with code that can perform string operations on its own variable names during execution, and has scope-less delay of symbol evaluation.
Posted on 2003-01-13 20:38:32 by NaN
dELTA,

Don't believe what he says, it IS really a wicked plot by Bill Gates and his cronies at Microsoft to drive you nutz so you end up giving up and buying a copy of Office at retail prices. :grin:

Regards,

hutch@movsd.com

-------------------
CEO Microsoft

Dear Bill,

I am really NOT happy about the number of bugz you have deliberately introduced into the free release of ML.EXE just to personally drive me mad.

I seriously think you should change this policy so that i do not end up writing code in Visual Basic.
Posted on 2003-01-13 23:30:54 by hutch--
Hutch, I just have to say that I find your attitude towards reporting bugs in free software a bit childish.

In this case I even wrote that the fault was most likely in my brain, but in earlier cases when I have really found bugs or at least limitations in MASM, it has been the exact same thing.

Every time someone even remotely insinuates that there might be a bug in the MASM compiler, you come rushing with one of your sarcastic and quite ridiculous "CEO Microsoft" posts (even though it was slightly more jokingly in this instance, although not really when seen in the light of your earlier posts).

So, shouldn't one be able to report bugs for free software? Is that your opinion? Won't the authors of free software appreciate bug reports (I know I do)? And is there maybe a separate commercial version of MASM?

Also, I'm relatively sure that the CEO of Microsoft (which is not Bill Gates for that matter) has better things to do than to process bug reports, so I'm quite convinced they have QA-personnel for that.

Sincerely,
dELTA
Posted on 2003-01-14 06:57:41 by dELTA
OOO! It's getting Hot in Here!

Take it easy dELTA. I'm sure Hutch was only joking around.
After all he's one of the main guys behind the MASM32 package.
A person doesn't put all that effort into something and then trashes it because of a little criticism!

He's progably a M$I (micro$oft spy) agent trying to cover his tracks after getting us hooked on MASM! I smell a conspiracy!:eek:

Martial_Code: The Conspiracy Theorist
Posted on 2003-01-14 07:47:48 by MArtial_Code
MArtial_Code, the MASM32 package and the MASM compiler are two different projects, with completely different developers.

As I said, I have gotten this kind of posts from hutch several times before, and all I meant is that I neither appreciate them, nor find them productive or meaningful. I don't want to flame anyone at all, my whole point is obviously about not flaming people.
Posted on 2003-01-14 08:18:20 by dELTA
dELTA,

The lesson to learn is not claim to be the judge of a softare product (M$ MASM) without knowing enough about it. As a matter of fact MASM has been known to have a few bugs in it here and there but it never stopped hundreds of thousands of people from writing successful code in it. I am right about the user number as a matter of fact.

What I suggest to you is that the bug is usually in the user, you, and that makes you like the rest of us, BUG creators, not assembler/compiler critics.

I have for years seen people whinging about bugs in a particular assembler/compiler and almost exclusively, the bugs are in the user, does your opinion make you any different ?

Now I am sure that the current CEO of Microsoft which I think from memory is Steve Ballmer would be more than willing to pass on your criticism to the organisation's founder, Bill Gates and on the sheer weight of you opinion he will modify hius organisation's approach to assembler design.

Now like I said before, start the letter like this,

Dear Bill,

I am not happy with the repeated failures of your freeware assembler to live up to my expectations and perform in the way I think it should. etc ....

Muhahahaha,

hutch@movsd.com
Posted on 2003-01-15 02:10:32 by hutch--