07-18-2023, 04:59 PM
(07-18-2023, 04:26 PM)Kernelpanic Wrote: @SagaraS - As already mentioned by bplus, this does not match the wiki. Either of them is wrong.
As one can see from the screenshot, the address actually shifts by 8 bytes. But what do SEGBlock.SIZE and SEGBlock.ELEMENTSIZE show then?
DIM AS _UNSIGNED LONG wert, wert1, wert2
Your SEGBlock.Offset is the memory address of where those variables are located in memory. Even if there's a gap of 1000 bytes between the first variable and the second, that doesn't change the behavior of how we interact with those blocks of memory. Most OSes don't tend to stack memory consecutively -- they place values with gaps between them as you're seeing with those offsets. The reason is rather simple -- what if you start with a string of 4 bytes in memory, and then you add to it to make it a string of 6 bytes? If all your data was stacked one bit of information packed tightly up against every other bit of information, you'd have to start moving data back and forth, and couldn't just append anything to the end of it. <-- This is basically the reason why variable length strings aren't easily usable via mem -- the OS might move and shift them at any point, to optimize how much memory your program has left available to it.
The Segblock.TYPE is the total value of the memblock that you're looking at. In the case above, the value is 1156 -- let's break it down as to what that represents:
1024 -- Unsigned
128 -- Integer (vs float/string/other -- it's the overall integer type and not 2-byte INTEGER)
4 -- Long
1024 + 128 + 4 = 1156 total <-- that's what we see for the mem.TYPE here.
The Segblock.Elementsize tells you how large each element is in memory -- in this case, an unsigned long uses 4 bytes in memory.
The Segblock.Size tells you the total amount of memory in this block -- in this case, it'd be 4 bytes total. (The same as the elementsize as we only have 1 element and not an array.)