atodw issue (also happens with atodJJ)

[patriciocs]

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:

Code Select Expand


.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?

[jj2007]

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".

[felipe]

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. 

[felipe]

You can do something like this:

Code Select Expand


.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:

Code Select Expand

mov ecx, dword ptr [eax + 020h] 

[aw27]

[TimoVJL]

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.

Code Select Expand

.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.

[patriciocs]

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.

[felipe]

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. 

[TimoVJL]

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.

[felipe]

   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...