cmpmem fails on data < 4 and binsearch problem..

[M4D45M]

when i tried to use cmpmem ..

setup:    fn cmpmem, "1234", "123?", 3
result:    eax = 0    ; mismatch
looking at the code:
  shr edx, 2    ; edx is len ; cmp is done dword-wise
; what if edx is < 4  eg. 03d
; 03d = 00000000000000000000000000000011b
; shr -> 00000000000000000000000000000000b
; so the count is zero but though the routine does one dword-wise cmp
; that doesn't make sense to me
; thus compares '1234' to '123?' which of course is unequal (but that wasn't the calling request anyway)

; the problem is that the function always starts with the dword-wise-comparison and only
; does a byte-wise-comparison for a remainder

; i highlighted my instertion
; it is: if data < 4 then jump to byte-wise-comparison

cmpmem proc buf1 :DWORD, buf2 :DWORD, bcnt :DWORD
    push esi
    push edi

    xor ecx, ecx
    mov esi, buf1
    mov edi, buf2

    mov edx, bcnt
     cmp edx, 4
     jl _byte_cmp
    shr edx, 2                      ; div by 4

  align 4
  @@:
    mov eax, [esi+ecx]              ; DWORD compare main file
    cmp eax, [edi+ecx]
    jne fail
    add ecx, 4
    sub edx, 1
    jnz @B

    mov edx, bcnt                   ; calculate any remainder
    and edx, 3
    jz match                        ; exit if its zero
    xor eax, eax                    ; clear EAX for partial writes

  _byte_cmp:
  @@:
    mov al, [esi+ecx]               ; BYTE compare tail
    cmp al, [edi+ecx]
    jne fail
    add ecx, 1
    sub edx, 1
    jnz @B

    jmp match

  fail:
    xor eax, eax                    ; return zero if DIFFERENT
    jmp quit

  match:
    mov eax, 1                      ; return NON zero if SAME

  quit:
    pop edi
    pop esi

    ret
cmpmem endp

; maybe you already knew but i didn't find anything about it by using the board search.

[M4D45M]

the other thing is, (to what i have no solution)

.data
szString db '_cor_.md5',0
szSub db 'core',0

.code
   fn BinSearch, 0, OFFSET szString, SIZEOF szString-1, OFFSET szSub, SIZEOF szSub-1

; result:    eax = 00000001h

; so the function says that the SUB was found at index 1 of the zero-based index into the STRING.
; that simply isn't true or maybe i'm just stupid
; i think there are no other possibilities left :D

[Mark Jones]

.data
szString db '_cor_.md5',0
szSub db 'core',0

.code
   fn BinSearch, 0, OFFSET szString, SIZEOF szString-1, OFFSET szSub, SIZEOF szSub-1

; result:    eax = 00000001h

; so the function says that the SUB was found at index 1 of the zero-based index into the STRING.
; that simply isn't true or maybe i'm just stupid
; i think there are no other possibilities left :D

I can't test your first question right now, but here I doubt that "SIZEOF" is doing what you think it will. A good test is to try something like this:

Code Select Expand


.data
    myVar       db "Hello world!...",0,0,0
.data?
    szResults   db 16 dup(?)
.code
    mov eax,SIZEOF myVar
    invoke DWTOA,ADDR szResults,eax
    invoke MessageBox,0,ADDR szResults,0,MB_OK


The idea is to take the integer SIZEOF value and convert it to a text string, then display it. "FN" also should be reserved for only those applications which need it, i.e. don't use it unless you must. Try this instead:

Code Select Expand


.data
    szString   db '_cor_.md5',0
    szSub      db 'core',0
.code
    invoke BinSearch,0,ADDR szString,9,ADDR szSub,4


If you need to attain the exact length of a data element, try:

Code Select Expand


myLength EQU (var2-var1)


The constant myLength will only be present at compile-time.

[hutch--]

When i get a bit more in front, I will tweak the cmpmem procedure as it does not appear to be handling data of less than 4 bytes in length correctly.

[M4D45M]

 first.
        why should i rather use invoke instead of fn ?
        (i always use fn coz it's faster to type and i think it is supposed to always produce appropriate code, isn't it?)

second.
         i use masm32v9 and it worx fine and without any magic,
         so why the hell would SIZEOF not produce appropriate results?
         in masm32 you can always get the size of a data-label by using SIZEOF.
         if you don't wanna include the null-terminator you just use SIZEOF-1.
         that's quite logical. sorry mark jones, can't follow your worries.

         and why bother using the myLength-thingy it would just suxx to always set it up,
         you'll never finish coding anything. that's for what SIZEOF is there.
         using it only makes sense when declaring multiline-strings.


         and why would i want to display the actual passed string-sizes?,
         ollydbg just does fine and i think the compiler can count correctly til 10
         and i also trust ollydbg to do and i think that i'm also able to.
         so why not consider that the BinSearch procedure is just wrong,
         just like the cmpmem procedure was?

        get the zip file and watch the content to see..

  cheers




[attachment deleted by admin]

[M4D45M]

.

[attachment deleted by admin]

[hutch--]

Posting images of a debugger are about as useful as a hip pocket in a singlet. To evauate whet the problem is with BinSearch I need to see some code, preferraby with a test piece that is reproducable.

[Mark Jones]

Look Madasm, either you can try my very generous suggestions, or you can hit the highway. Choice is up to you.

[M4D45M]

see, i said i dunno whats the problem is with BinSearch.
the only thing i know is that it fails on this input:
szString db '_cor_.md5',0
szSub db 'core',0

and the pix aren't useful in fact. i just wanted to prove mark jones
there's no problem with SIZEOF and
that his suggestion wasn't right coz it suggested me being too stupid,
in turn i showed up that the procedure is stupid, not i.

the source code i included (archive01) just has the setup for BinSearch to fail.
one can now reproduce the failure of BinSearch in his/her debugger
and see for himself/herself.
so that's it. i accidentally realized that BinSearch fails on this input,
so i wanted you to know, coz BinSearch might then also fail on some other input.

[Mark Jones]

i just wanted to prove mark jones
there's no problem with SIZEOF and
that his suggestion wasn't right coz it suggested me being too stupid,
in turn i showed up that the procedure is stupid, not i.

I never said you were stupid, and would never insult someone I do not know. (I also do not tolerate any bull-%^!@.)

Here are some of the limitations of the FN macro in MACROS.ASM:

Code Select Expand


  ; ----------------------------------------------------------------
  ; invoke enhancement. Add quoted text support to any procedure
  ; or API call by using this macro instead of the standard invoke.
  ; LIMITATION : quoted text must be plain text only, no ascii
  ; values or macro reserved characters IE <>!() etc ..
  ; use SADD() or chr$() for requirements of this type.
  ; ----------------------------------------------------------------


And there IS an obscure "problem" with SIZEOF:

Hello World! SizeOf fails for multiple lines.
SIZEOF: 13 bytes.
EQU Calculation: 48 bytes.
Press <ENTER> to exit.

Code Select Expand


include masm32rt.inc    ; assemble as a console app

szHelloSize EQU (szJunk2 - szHello)

.const
    szJunk1     db "Test 1 2 3...",0
    szHello     db "Hello World! "
                db "SizeOf fails for multiple lines.",13,10,0
    szJunk2     db "Test 1 2 3...",0
.data
    szResult1   db "SIZEOF: xx bytes.",13,10,0
    szResult2   db "EQU Calculation: xx bytes.",13,10,13,10,0
.data?
    szBuffer    dd ?
.code
start:
    invoke StdOut,addr szHello                  ; print test string
    mov eax,SIZEOF szHello                      ; get size of it
    invoke dwtoa,eax,addr szBuffer              ; convert to ASCII
    mov ax,word ptr [szBuffer]                  ; copy two bytes
    mov word ptr [szResult1+8],ax               ; to dest string
    invoke StdOut,addr szResult1

    mov eax,szHelloSize
    invoke dwtoa,eax,addr szBuffer
    mov ax,word ptr [szBuffer]
    mov word ptr [szResult2+17],ax
    invoke StdOut,addr szResult2

    mov eax,input("Press <ENTER> to exit.")
    invoke ExitProcess,0
end start


[hutch--]

Code Select Expand


; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    include \masm32\include\masm32rt.inc
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

comment * -----------------------------------------------------
                        Build this  template with
                       "CONSOLE ASSEMBLE AND LINK"
        ----------------------------------------------------- *

    .data
      szString db "_cor_.md5",0
      szSub db "core",0
      szSubX db "_cor_",0

    .code

start:
   
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

    call main
    inkey
    exit

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

main proc

    cls

    invoke BinSearch,0,ADDR szString,LENGTHOF szString,ADDR szSub,LENGTHOF szSub

    print str$(eax),13,10

    invoke BinSearch,0,ADDR szString,LENGTHOF szString,ADDR szSubX,LENGTHOF szSubX

    print str$(eax),13,10

    ret

main endp

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

end start


Output is,

Code Select Expand


-1
0
Press any key to continue ...


As per the documentation for the procedure. Check the documentation for the procedure in masmlib.hlp. Thats what its supplied for.

[M4D45M]

i already wrote that i'm aware of that SIZEOF doesn't work for multilines,
(i wrote it in the post an in the example of archive01)

and i packed the BinSearch procedure of the masm32package i downloaded
into archive01 coz this proc. does fail,
thus the fact that hutch's test seems to succeed, i'll have to get me a newer
version of the procedure.

so it just seems that i have an outdated/not working version of BinSearch

though of the misunderstandings, (without them we could have come to clarity faster)
thanx anyway

[hutch--]

Strange,

The version in the current masm32 was written 2 years ago. You must have a really ancient version.