Question about this code(HLReference)

[Rainstorm]

hi,..

the following code works proper..but i have a question.
lcase$ works on a zero-terminated-string.
here the variable night doesn't contain a zero-terminated-string. - so how come it
works proper then ?
(night    db "PIXIE",0    --would be a zero-terminated-string..right ?)

Code Select Expand

    .data
night    db "PIXIE"
; -------------------------------------------------------------------------

    .code
start:
mov  ebx, lcase$(offset night)

print ebx,13,10

inkey
exit
end start

Thankyou.

[dsouza123]

Uninitialized memory can have any byte value including a 0,
there must have been 0 byte in this case so it worked this time,
but it could just as well been some other random bytes and
your string would have a bunch of garbage characters following
the real text string.

[ic2]

There should be no following characters (garbage) unless you have another string other than *code* in front of it. Is this not correct?

Place other strings around it and see what happen...

[hutch--]

Rainstorm,

Microsoft have a humerous way of describing this situation, they refer to the results as "Undefined" which mean anything from random garbage to system crashes. The masm32 string library procedures all expect zero terminated strings so you should normally use them. What has probably happened is the initialised data section was filled with zeros.

[Rainstorm]

hi,

So, is it automatically reading one byte more from memory ?
(..as the reason is, that the initialised data section is filled with 0s)
Since if it wasn't doing that, the other bytes being a 0 wouldn't have made a diff.
am i right ?

Is it in this instruction that it is reading one byte beyond the variable,  night ?

mov  ebx, lcase$(offset night)
______________

hutch wrote..

The masm32 string library procedures all expect zero terminated strings so you should normally use them...

- I was gonna ask that next just to be sure.

.. since in the help file for some functions like add$ & istring (for example) it
just says 'string' , while for other functions..'zero-terminated-string' is. explicitly mentioned.
___________________

ic2 wrote...

Place other strings around it and see what happen...

I tried 2 things

mov  ebx, left$(lcase$(offset night),3)   - here it returned the right result 'pix'

mov  ebx, right$(lcase$(offset night),3)   - that just returned 'e' insstead of 'xie'

why is it reading from beyond the defined variable in this case ?

Thanks all..

Rainstorm.

[Rainstorm]

can someone clarify this for me.

why does it read beyond the variable size in a decleration like the following

night    db "PIXIE"

is it because, the memory is read in Dword chunks ?

t y

[Relvinian]

can someone clarify this for me.

why does it read beyond the variable size in a decleration like the following

night    db "PIXIE"

is it because, the memory is read in Dword chunks ?

t y

Just taking a guess because I don't know what your code is doing, but here goes:
Try adding a NULL terminator to the end of your string definition, like this:

Code Select Expand


night  db "PIXIE", 0


See if that helps...If not, post the segment of code you are using your string in and I'll be able to answer more correctly.

Relvinian

[kermit]

why does it read beyond the variable size in a decleration like the following

night    db "PIXIE"

is it because, the memory is read in Dword chunks ?

no, its because the "machine" just doesn't know the actual length of ur variable. it takes one byte after the other from this address until it gets a 0 byte.
if u want to see what happens u might want to use a debugger, i tried ollydbg http://www.ollydbg.de/ which works nice for 32 bit code.

greetz,

kermit

[Rainstorm]

Kermit, thanks so much for the explanation & clearing that up for me.. :-)

-