simple memory question

[ecube]

how many bytes can fit in

mv byte 256 dup(?)

because I did

Code Select Expand


.686p
.model flat, stdcall
option casemap:none

include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
include \masm32\include\user32.inc
include \masm32\include\masm32.inc
includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\user32.lib
includelib \masm32\lib\masm32.lib

.data?
uu byte 100 dup(?)
mv byte 1 dup(?)

.data
lst byte '123456789012345678901234567899abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvvvv',0

.code
start:
invoke lstrcpy,addr mv,addr lst
invoke lstrlen,addr mv
mov ecx,eax
invoke dwtoa,ecx,addr uu
invoke MessageBox,0,addr mv,addr uu,MB_OK
invoke ExitProcess,0
end start


and that actually fits...107 byte string in a 1 dup(?) i'm extremely confused

[ramguru]

Your source-code is fucked-up  :snooty: But anyway (was) to answer your question. You have just exceeded the bound of your variable, it's up to you to do so, no-one is telling you when that happens, variable is just a pointer. Even if you declare one variable in a certain section, that section is usually bigger (how much bigger is described in PECoff documentation IIRC it's "Size Of Init Data" sizeof(rdata+data)). But eventually you'll get access violation error, if you'll be playing like that. Byte is Byte and Word is Word don't assume more...

[Mark Jones]

Indeed, the moment you declare a single byte of (?) data, an entire kilobyte of memory is reserved. The first term, UU, points to the very beginning of this block. The second term, VV, points to a location 101 bytes later. However, there is still 899 unused bytes in that memory section, so it is possible to "overflow" the 1-byte "variable" to a maximum of 898 bytes, after which point you would get an exception error, namely a "page fault", since you then would be trying to write over some other "page" of memory that does not belong to you.

[ecube]

Alright thanks a lot guys, at first I thought it was overwriting somthing but when it didn't crash with more data I put into it... I was under the illusion the "dup" buffer actually expands itself in memory like GlobalRealloc heh.