The MASM Forum Archive 2004 to 2012

Japheth has already made an attempt (http://www.masm32.com/board/index.php?topic=9835.msg72092#msg72092) to list the known MASM bugs. I think it would be extremely useful for beginners and seasoned programmers alike to find these bugs condensed in a list, maybe together with possible workarounds.

I start with three simple examples:

1. The programmer can pass more arguments to a macro than needed. ML 6.14 and ML 9.0 issue only a warning (A4006:too many arguments in macro call), although the MessageBox will look a bit odd. JWasm recognises this as an error.


2. Assembly gets slow, and ML may eventually freeze, for large buffers in the .data? section:


The workaround is a macro using the ORG directive (I owe this idea to drizz (http://www.masm32.com/board/index.php?topic=8602.msg62638#msg62638)and MichaelW):

(EDIT: link to drizz' post added - thanks Michael)


3. The offset problem: Both versions of this code work for ml 6.14 and JWasm but ml 9.0 says error A2070:invalid instruction operands

No workaround found yet, except sacrificing a register...

JJ,

Here is another bug in MASM 8.0 AND still in MASM 9.0. I reported this to MS:
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=356393

Dave.

JJ,

Here is another one.

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=362492

Dave.

JJ,

The workaround for big buffers in the .data? section was from drizz, I just tested it.

http://www.masm32.com/board/index.php?topic=8602.msg62638#msg62638

So what are you asking poor ml to do, Dave? What is the meaning of an "empty argument"?

EDIT: Strangely enough, the empty argument is not the culprit - the commas after PROTO and PROC are being ignored.
Since REC_PTRS EQU 12:


What is the purpose of INVOKE Calc, OFFSET [esi+12] ? How does it differ from INVOKE Calc, [esi+12] ?

Here is a minimalist demo of this behaviour:


MSDN is, as usual, incredibly verbose about the exact meaning of "offset":

Microsoft Macro Assembler Reference (http://msdn.microsoft.com/en-us/library/009k3eeh(VS.80).aspx)
operator OFFSET

Returns the offset of expression.

The Masm workaround I use for the large BSS data is:

.data?
COMM MyBigBuffer:dword:12345678

Which creates a buffer of 12345678 dwords. No messy macros, but probably doesnt work in other assemblers.

As for other bugs... I don't even know where to begin in regards to all the quirks of the macro language that have become 'features'

The problem with OFFSET is that this operator has become ambiguous.

The - original - purpose of the OFFSET operator is to return the offset part of a label. For Masm, a label consists of segment, offset and type information. From this point of view, it's illegal to feed OFFSET with an indirect memory operand ( and JWasm is wrong to accept [esi+0], this will be fixed).

However, OFFSET in Masm additionally accepts numbers, structure names and structure fields, which aren't labels. The "offset" of a structure field is a useful information, but "offset" of numbers/structure names are useless. Also, IMO, since structure fields are accepted as operands, there's no good reason why stack variables are NOT accepted?

A word of caution:
Communal Data Is Not Included in the LIB Listing (http://support.microsoft.com/kb/79857)

Communal data declarations generate no PUBLIC definitions. Therefore, although they can be placed in a library, they are not placed in the library dictionary and will not be a part of the library listing generated by the LIB utility.

Communal variables are supported only by QuickC, Microsoft C versions 5.0 and later, and MASM. They are, however, similar to common blocks in FORTRAN. In C, communal variables are the uninitialized global data items. In MASM, they are data items declared with the COMM qualifier.

The linker will assume the communal variables refer to an external defining declaration elsewhere. If there is no external definition, the linker allocates storage and initializes it to 0 (zero). If there is more than one declaration, storage is allocated for the largest data item declared. For example, if I is declared int I; in one module and char I; in another module, the linker will allocate 2 bytes for I because the int is 2 bytes but the char is only 1 byte. Because memory for communal variables may not be assigned until load time, their use may reduce the size of your executable file.

When a communal variable is declared in a library and defined in one of the object modules, references to that variable will be resolved with the defined variable. For this reason, communal variable declarations are not recommended for any file that might be placed in a library. If a variable defined in a .OBJ file accidentally had the same name as a communal variable in a library that it is being linked with, its value would unexplainably change every time you called a library function that used that communal variable! The linker does not issue a warning because the variable was defined only once, in the OBJ file.


Every language has its known prob... pardon: features. The ones that 'count' are those that lead to endless unnecessary bug searches. In this context, there should be a Beginner's Guide to Masm Quirks. This should include serious Masm bugs, but also simple things like the ABI ("why does the beast destroy my precious eax?"), and hints to common errors such as ".if eax<-3" - I spent a lot of time chasing this "non-bug" simply because I didn't know that Masm was stupid enough to treat eax as unsigned. Since then I happily use

signed equ sdword ptr
.if signed eax<-3

The two most serious bugs that are present in ml versions prior to 9.00.30729.01 are:
1) pushing of non dword variables/registers in invoke (also the zero/sign extension is silly)
2) dup with initialized structs

here's a link to more links :)
http://www.masm32.com/board/index.php?topic=8758.msg63746#msg63746

the workaround is to use the JWASM  :U. Or the latest version of ml

Just found another cute "bug":

mov eax, [esi+ecx+ebp-14]

gets without warning encoded as

mov eax, [ecx+ebp-14]

I urgently needed that three-register address mode, but no luck :bg

Problem solved:

Both versions work with ml 6.14, 6.15, 9.0 and JWasm.