Code: Select all
*mem = AllocateMemory(4096) ; allocate 4096
For i = 1 To 6000 ; using 6000 instead 4096
PokeB(*mem+i,$FF)
Next
[Implemented] Maybe the debugger should catch this !?
[Implemented] Maybe the debugger should catch this !?
when allocating some memory and if you try to write outside the allocated area (buffer overflow), even the debugger crashs! maybe the debugger could check this instead crashing?
Not a bug, might have wanna put it in feature request forum instead.
Plus, if the compiler where to check things like that the compiler would be very slow,
and it would make it impossible to read/write outside allocated memory
(which sometimes is wanted, esp with shared memory programs and much more)
Instead I suggest that if you fear that a certain loop may go out of bounds,
then you should always add a check to that loop against the size you allocated.
usually when you allocate memory it is wise do do things like:
buffersize=4096
*buffer=AllocateMemory(buffersize)
That way you can easily do a:
max=6000
if max>(buffersize-1) ;or -2 or -4 depending on if you do long, word or byte.
For i = 1 To max ; using 6000 instead 4096
PokeB(*mem+i,$FF)
Next
or alternatively.
max=6000
For i = 1 To max ; using 6000 instead 4096
If i>=buffersize : break : endif
PokeB(*mem+i,$FF)
Next
The best way to code it however would be:
This is the "proper" way to code, and you should never have out of bounds crashes.
And the loop is also dynamic in that it'll work with any allocated size.
PS! As for the debugger, may be possible for it to catch.
But personally I advice you to use the OnError library functions,
as they will catch illegal memory writes etc, and allow your program to catch it, and even possibly handle it, cleanup after itself and exit properly.
(this avoids potential system instability and trashing too).
Plus, if the compiler where to check things like that the compiler would be very slow,
and it would make it impossible to read/write outside allocated memory
(which sometimes is wanted, esp with shared memory programs and much more)
Instead I suggest that if you fear that a certain loop may go out of bounds,
then you should always add a check to that loop against the size you allocated.
usually when you allocate memory it is wise do do things like:
buffersize=4096
*buffer=AllocateMemory(buffersize)
That way you can easily do a:
max=6000
if max>(buffersize-1) ;or -2 or -4 depending on if you do long, word or byte.
For i = 1 To max ; using 6000 instead 4096
PokeB(*mem+i,$FF)
Next
or alternatively.
max=6000
For i = 1 To max ; using 6000 instead 4096
If i>=buffersize : break : endif
PokeB(*mem+i,$FF)
Next
The best way to code it however would be:
Code: Select all
buffersize=4096
*buffer=AllocateMemory(buffersize)
if *buffer=0 : Goto error : endif ;always check if the memory was allocated or not.
For i = 1 To (buffersize-1) ;-1 if bytes, -2 if word, -4 if long
PokeB(*mem+i,$FF)
NextAnd the loop is also dynamic in that it'll work with any allocated size.
PS! As for the debugger, may be possible for it to catch.
But personally I advice you to use the OnError library functions,
as they will catch illegal memory writes etc, and allow your program to catch it, and even possibly handle it, cleanup after itself and exit properly.
(this avoids potential system instability and trashing too).
> Not a bug
Agreed. In the example given it's obvious that you're poking outside of what
you allocated, but in a real-world app the debugger has no business deciding
what you want to do with Pokes.
Agreed. In the example given it's obvious that you're poking outside of what
you allocated, but in a real-world app the debugger has no business deciding
what you want to do with Pokes.
I compile using 5.31 (x86) on Win 7 Ultimate (64-bit).
"PureBasic won't be object oriented, period" - Fred.
"PureBasic won't be object oriented, period" - Fred.
yes i know its not a bug of pure! its a bug by the programmer! i only thought it would/could be nice if the debugger check this instead crashing...PB wrote:> Not a bug
Agreed. In the example given it's obvious that you're poking outside of what
you allocated, but in a real-world app the debugger has no business deciding
what you want to do with Pokes.
