Hello, it's me again here in my MASM journey. I have an issue I've spend the whole day trying to find out why happened but I haven't found the reason. I am trying to use the atodw macro in order to convert a 4 character ascii string to a number. Numbers in this string are stored with leading zeroes, e.g. "0001", but when are passed to atodw it return values that are nowhere close to the right one.
The function receives a 200 characters string (Cadena), then I extract the 4 characters starting at 020h and I need that to be converted to it's values. The code is like this:
.data
tmpComm db "0000",0
.code
getComandoNum proc Cadena:DWORD
mov eax, [Cadena]
mov ecx, dword ptr [eax + 020h]
mov dword ptr [tmpComm], ecx
invoke atodw, ADDR tmpComm
Ret
getComandoNum endp
After this is executed I check EAX but it have any number but the one in the string. Per example for Cadena = "000000000000000000000000000000000090000000000000000000000000000000000000000000000000...0" it should return 9, but it returns 16716 (414Ch).
I tried using the function atodJJ I found here in the forum but the result is the same. Any thoughs of what could be wrong here?
Strings are zero-delimited, and that means 0 bytes, not the character "0". Your "000000000000000000000000000000000090000000000000000000000000000000000000000000000000" is 84 bytes long, so it would return an absurdly high number, well above the 32-bit range of atodw. You need to feed it with smaller strings, such as "1234" or "123456789".
You are taking the character "0090" from the string and putting it in the start of the string, but if you do not zero terminate that string then the function will try to give you the dword value of a string which was not the intended. :icon_idea:
You can do something like this:
.data
tmpComm db "0000",0
.code
getComandoNum proc Cadena:DWORD
mov eax, [Cadena]
mov ecx, dword ptr [eax + 020h]
mov dword ptr [tmpComm], ecx
XOR EAX,EAX
MOV DWORD PTR tmpComm + 4,eax
invoke atodw, ADDR tmpComm
Ret
getComandoNum endp
But it will give you 90 as the value in eax (the return value). You should be aware of what are you addressing with this line of code: mov ecx, dword ptr [eax + 020h] :icon_idea:
(https://www.dropbox.com/s/xakod7pmn5o34gd/brackets.jpg?dl=1)
Quote from: patriciocs on August 15, 2019, 07:43:28 AM
After this is executed I check EAX but it have any number but the one in the string. Per example for Cadena = "000000000000000000000000000000000090000000000000000000000000000000000000000000000000...0" it should return 9, but it returns 16716 (414Ch).
Cadena points wrong place ?
That function returns 90 (5Ah) in this test, as array is zero based.
.386
.model flat, stdcall
option casemap :none
atodw proto stdcall :dword
.data
cmdLine db "000000000000000000000000000000000090000000",0
tmpComm db "0000",0
.code
getComandoNum proc Cadena:ptr
mov eax, Cadena
mov ecx, dword ptr [eax + 020h]
mov dword ptr [tmpComm], ecx
invoke atodw, ADDR tmpComm
ret
getComandoNum endp
.code
mainCRTStartup proc
invoke getComandoNum, addr cmdLine
ret
mainCRTStartup endp
end mainCRTStartup
felipe and AW gave hints what to look.
thank you very much guys. I included felipe code and it worked perfectly. Well, getting 90 or 9 wasn't the issue I was trying to address here (I think I forgot to type a 0 at the beggining of Cadena), but that it wasn't returning a correct transformation at all. After Felipe code's addition it worked perfectly. Now I am trying to understand what those two lines do that fixed my issue.
Quote from: patriciocs on August 16, 2019, 01:19:22 AM
Now I am trying to understand what those two lines do that fixed my issue.
That's good. If you can't get the answer you can ask here again. :winking:
Quote from: patriciocs on August 16, 2019, 01:19:22 AM
Now I am trying to understand what those two lines do that fixed my issue.
Actually nothing, as
tmpComm db "0000",0 was correct for register / DWORD size.
:biggrin: i wrote those 2 lines of code for the "0000000000....90000...." string that you commented as an example. I didn't change that in the code above. Now you know how sloppy i am... :toothy: