News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

atodw issue (also happens with atodJJ)

Started by patriciocs, August 15, 2019, 07:43:28 AM

Previous topic - Next topic

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:


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

felipe

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:


TimoVJL

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.
May the source be with you

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

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:

TimoVJL

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.
May the source be with you

felipe

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