lstrlen and len equ $-var

[Nilrem]

Let's just say I have a var that is the following:
var db 098h, 098h, 098h
and then underneath this I have:
len equ $-var
This makes sure that len equals (gets the number of bytes, right?) of the variable?
However when altering the value (via user input) of var len equ ceases to work.
My question is this, can I do something to a similar effect via the api lstrlen? Here is what I have (though I feel it is incorrect because my code doesn't work as it once did, yes once upon a time I had working code  :eek)

Code Select Expand


.data

temp dd 0
var db 098h, 098h, 098h

.code

invoke lstrlen, addr var
mov temp, eax

Now will should temp hold the same value as len equ used to, if so I have a bug in my code that is resisting the squatter (metaphors got to love them).




Once again thanks for been patience with an endless question asker, or as I prefer 'seeker of knowledge'.

[Nilrem]

Ahh I have found my problem using a debugger. I use lstrcpy to copy two strings together, but they aren't actually strings, it's like it is in my example above (though I always thought a string was an array of values). lstrlen is returning the correct value of 6 (6 bytes), but the bytes are no longer numbers. Though the only reason I am using lstrcpy is because he m2m macro or push/pop is not working for me, see the condition jump thread, should (hopefully) be nearby.

[P1]

Don't forget to zero terminate your strings.

Code Select Expand

var db 098h, 098h, 098h, 0h

Regards,  P1  :8)

[Nilrem]

so when searching for bytes it wouldn't search for the 0 at the end would it, also do strings always have to be null terminated when you manipulate them? Thanks.

[mnemonic]

I don't know what you mean by 'searching for bytes'.
It is common practice that text-strings are zero terminated at least under Windoze but I think it is the same under *nix os's. Such strings are also refered to as C-strings (it simply is the way C handles strings). If you use string functions like strlen they will handle the strings up to the zero byte (e.g. the length of the string minus the zero byte).

[Nilrem]

Well it isn't really a string it's just
var db 098h, 098h, 098h I have code that searches for a byte pattern like this, but it only works because it isn't specifically a string, (like it moves the values one byte at a time, if it was a string this wouldn't be possible I don't think).But I have to use string manipulation because the m2m macro is not working for me, if you see the other thread the jeanxz one.

[Mark Jones]

Any string-related function (lstrcpy, lstrcat, etc.) stops reading "string data" at the 00h position - the 00h marks the "end-of-string."

If your data has no 00h at the end, string functions will just keep going until a 00h is found.

Say your code is this:

Code Select Expand


.data
myVar1  DB  89h,89h,89h
myVar2  DB  "Hello there! This string causes a problem...",0


And myVar1 == ptr 0041001E. The compiled data looks likes this:

Code Select Expand


00410010:  00 00 00 00 00 00 00 00   00 00 00 00 00 00 89 89
00410020:  89 62 E1 51 F0 02 33 20   25 92 2A 31 77 19 11 42...


"myVar2" pointer == 00410021. Understand?

[P1]

so when searching for bytes it wouldn't search for the 0 at the end would it, also do strings always have to be null terminated when you manipulate them? Thanks.

When using W32 API string functions, remember the string limitations, regardless of what the data is.  And if there is embedded zero value data, don't use W32 API string functions. 

When your code breaks and your debuging it as you trace through it.   Remember that we told you before hand.

Regards,  P1  :8)

[Nilrem]

Yep, thanks. Looks like I need my m2m problem solving in the jeaxnz thread.

[AeroASM]

Well it isn't really a string it's just
var db 098h, 098h, 098h I have code that searches for a byte pattern like this, but it only works because it isn't specifically a string, (like it moves the values one byte at a time, if it was a string this wouldn't be possible I don't think).But I have to use string manipulation because the m2m macro is not working for me, if you see the other thread the jeanxz one.

Strings are nothing different from lists of bytes, in fact the only way to manipulate them is to move them one byte each. (Or one dword each if you know what you are doing).

Also, m2m will not work for strings, because push/pop only work with word and dword, not many different bytes.

There is no way to determine the length of a variable unless there is some terminating sequence to signify the end. In the case of strings, it is a convention used by all Windows APIs to use 0h as a terminator for strings.

[tenkey]

so when searching for bytes it wouldn't search for the 0 at the end would it, also do strings always have to be null terminated when you manipulate them? Thanks.

Only if you use functions supplied by the API or any C-compatible library. Any which way you manipulate the strings, before using the Win32 API functions, the strings must be in C-compatible form - null terminated. (As a side note, the ReadFile and WriteFile functions do not read or write C-compatible "strings". They read and write binary data.)

There are other ways to store strings. Old VB uses BSTRs which store a string length at the beginning of each string. You can create "descriptors" for each string, so that data and length information are kept separate. You can store strings in bits and pieces, with a linked data structure to define the sequencing of the string data. The last approach is best used when working with very large strings and lots of little changes, similar to text editting applications.