this time, MASM really pissed me off  :mad:  :mad:

try this:


      .586
      .model flat, stdcall
exit proto code:dword
.data
        buf db 10 dup (?)
.code
        invoke  exit, buf
Posted on 2007-03-01 10:23:30 by vid
Well, first of all, do you have a function body for "exit"? Furthermore, you should pass the address of the buffer, like this:


invoke exit, addr buf
Posted on 2007-03-01 13:30:28 by Seb
this is not a real problem, this is demonstration of how stupid MASM beheaves in this case. Is this bug known? Was it reported to MS?
Posted on 2007-03-01 14:20:56 by vid
I'd say you're alone to consider the need to pass the address of a byte-array to a function a "bug" - MASM is not stupid, it's just the way it works. Or am I misunderstanding you here? What is the actual problem?
Posted on 2007-03-01 16:37:03 by Seb
you are not understanding - i already got it confirmed on ALA.

I am passing byte to dword-sized argument, and MASM fails to properly zero-extend it to dword, it extends it to 6 bytes instead.
Posted on 2007-03-01 16:55:08 by vid
MASM is buggy - what else is new? ;)
Posted on 2007-03-01 17:39:33 by f0dder
nothing, i just forgot to type "offset" and wasted to days with searching where is problem, until i noticed stack is unbalanced and traced it here.
Posted on 2007-03-01 18:02:13 by vid
This is a well-known bug of masm, vid :)
But we last discussed it around 2 years ago (before you joined), so the thread is lost somewhere in the sea of threads here :)
Posted on 2007-03-01 20:59:46 by Ultrano
has it been reported? Considering recent success with reporting structure/DUP error...
Posted on 2007-03-02 01:39:02 by vid
masm6.x is the only worthy version to use, and I doubt MS will fix issues in it. (since ml 8.x is out). So, it's useless to report anything. Using ml8 for macro-asm coding is ok... as long as you're working on tiny projects. I can't begin to convey what hell it is to use ml8 for big projects, written in asm.

Thus, once you've experienced each of the few bugs masm has, you'll know innately when masm won't assemble a line correctly.
Though, except for this and the struct-init bugs, I don't remember others - to provide you with a "reference". I simply avoid them automatically, without thinking ^^" (already a bit more than a million lines under my belt).
Posted on 2007-03-02 01:52:45 by Ultrano
If you want to pass the address of the buffer, prototype the function with

exit proto code:ptr byte

instead of the generic "dword"

then ML will give you

error A2114: INVOKE argument type mismatch : argument : 1

and you won't be chasing stupid errors in the actual exe...
Posted on 2007-03-02 02:03:14 by sinsi
thanks, i already did it. Even a few PTR DWORDs.
Posted on 2007-03-02 08:28:27 by vid
BUT EVERYTHING IS A DWORD IN ASSEMBLY OMFG!

;)
Posted on 2007-03-02 09:24:48 by f0dder

BUT EVERYTHING IS A DWORD IN ASSEMBLY OMFG!

;)



I beg to differ for my 16-bit Initialization Code :P
Posted on 2007-03-02 11:48:49 by SpooK
of course everything is dword  :P :), that is, everything is "cpu word"-word.

vid if you type "buff SBYTE 10 dup(?) " it will extend it.
The bug was discussed and reported long time ago. (it is not fixed even in version 9)

so use movzx before proc

Posted on 2007-03-03 12:06:46 by drizz