Hi all. I don't really know if this is the appropriate forum but it could fit here. Anyway I've been trying to write a string removal procedure with the following conditions:

    [*]Accepts a pointer to location to remove string
    [*]Removes n characters starting at the location

    Here's an example:
    
    
    .data
    someString BYTE "1234vvvv5678",0
    .code
    INVOKE str_remove,ADDR [someString+3],4

    That code would instruct the procedure to remove "vvvv". So far I have thought of two methods, both failures:

      [*]Starting with the first character to be removed, copy the following byte into the current position and advance the pointer. This, however, results with only the last "v" being replaced with a "5".
      [*]Starting with the last character to be removed, copy the following byte into the current position and move the pointer back one.

      Does anyone have a method for doing this? I don't want any code (pseudo-code is fine) because I'd like to try and accomplish this myself. I know this is pretty basic, but I've been stuck for quite some time. Any help is greatly appreciated :alright:
Posted on 2004-04-13 19:46:18 by DaRetard
Keep two pointers - source and destination. Destionation = first char to remove, source = first char to remove + count of chars to remove. Get from source, store in destination, advanced both pointers. If the char you just copied isn't zer0, continue looping.
Posted on 2004-04-13 20:21:07 by f0dder
Afternoon, DaRetard.

Something like this possibly:



str_remove PROC uses edi esi l_ptrString:DWORD, l_dwLength:DWORD

mov edi, l_ptrString ; Pointing to start of removal.
mov esi, l_ptrString
add esi, l_dwLength ; Pointing to the rest of the string to concatenate.

@@:
lodsb ; Load character from esi address; esi incremented to next character.
stosb ; Store that character at edi address; edi incremented to next character.
cmp al, 0 ; Have we found the terminating zero?
jnz @B ; Nope, so jump back to do the next character.

; Substring removed.

ret
str_remove ENDP


You'd also want to use:


invoke str_remove, ADDR [myStringToTest+4],4

if you wished to remove those vvvv's.
Using


invoke str_remove, ADDR [myStringToTest+3],4

would start the removal at the fourth character, which is '4' in your string.

Cheers,
Scronty

I must be damn slow:grin: . There were no replies to this thread when I started chucking together a solution:( .
At least I was able to create a test proggy to make sure the proc I've shown actually works as intended :alright:
Posted on 2004-04-13 20:36:31 by Scronty
You might want to first scan from the beginning to make sure that your offsets don't go past the end of the string. Either that or make very certain you know the length of the string beforehand.

Also make sure that the altered string length doesn't also alter your conceptions of the buffer length. Promote safe string handling. :alright:
Posted on 2004-04-13 22:31:43 by iblis
Exit if the string if iStart is beyond the end of the string.

lszCut FRAME pString,iStart,nLen


mov edi,[pString]
mov esi,edi
mov ecx,[iStart]
add esi,ecx
add esi,[nLen]

xor eax,eax
repne scasb
or ecx,ecx
jz >
ret
:
mov al,[esi]
mov [edi],al
inc edi
inc esi
or al,al
jnz <

mov eax,[pString]
RET
ENDF
Posted on 2004-04-13 23:43:19 by donkey
Scronty and donkey :P

Does anyone have a method for doing this? I don't want any code (pseudo-code is fine) because I'd like to try and accomplish this myself.
Posted on 2004-04-13 23:48:09 by f0dder
Afternoon, lying viruswriting pirate.

He can always use what we showed to compare with what he himself comes up with.:alright:

Going by my own coding skills, my solution would not be the better algorithm.:sweat:

Cheers,
Scronty
Posted on 2004-04-14 05:38:46 by Scronty
Thanks for all the ideas guys. I hadn't implemented error checking, so thanks for that tip. I ended up using f0dder's idea: "Destination = first char to remove, source = first char to remove + count of chars to remove." Also Scronty I tried using the ADDR and for some reason it didn't remove the first v. Using ADDR did work however. Again thanks guys :grin:
Posted on 2004-04-14 07:57:55 by DaRetard

Going by my own coding skills, my solution would not be the better algorithm.

It was easy to follow, and that's somewhat more important than "the best code" when helping people out :alright:.
Posted on 2004-04-14 10:05:57 by f0dder