Debugger should warn, if a variable value is too large

[Sicro]

The debugger already warns, if a too large value is assigned to a variable:

Code: Select all

b.b = 9223372036854775807 ; Line 1: Overflow error: a 'byte' value (.b) must be between -128 and +255

but the debugger should also warn, if a too large value of another variable is assigned to a variable:

Code: Select all

value.q = 9223372036854775807
b.b = value ; No error
a.a = value ; No error
w.w = value ; No error
u.u = value ; No error
l.l = value ; No error

[Dude]

Deleted, it seems I gave wrong info.

[Josh]

@Sicro
The warning isn't send by debugger, the warning is send by compiler, so I don't think that this makes sense. This works in your simple example, but:

- Should it still work with a statement like b.b = value * 2?
- What if the assignment value.q = 9223372036854775807 is in an If statement?
- And so on, and so on


@Dude
Sorry Dude, but that's a full-blown bullshit.

[Derren]

Checking for overflow everytime a variable is changed would slow the programm down by a lot.
You can easily write yourself a macro to do this (still slowing everything down, if you use it everytime). But this way you can address Josh's question about "var * 2" individually.
Last but not least, overflowing is wanted and needed sometimes.
You shouldn't use byte anyway, if you don't want to use the "inbuilt" over- and underflow bevahiour, as stated by the help file (somewhere). Using Integer is faster, even if you know your values will never exceed 128

[Sicro]

The warning isn't send by debugger, the warning is send by compiler, so I don't think that this makes sense.

Okay, in this case, such a check is nonsense. As you mentioned, for example, with an if-block all cases would have to be tried.

The PB help describes that the purifier of the debugger checks not only memories but also variables, whether the current process reads or writes outside the valid range (PB help page (At the bottom of the page):

The purifier detects these errors by placing a special 'salt'-value around global and local variables, strings and allocated memory buffers.

Looks like the purifier isn't working properly then.

Checking for overflow everytime a variable is changed would slow the programm down by a lot.

According to PB help the check is the task of the purifier of the debugger and the debugger is only used at the development time and not in the final product, so it doesn't matter if it slows down the speed of the program code during this time.

Last but not least, overflowing is wanted and needed sometimes.

Okay, I don't have any experience with that.

Using Integer is faster, even if you know your values will never exceed 128

I always use variables of the type "integer" unless another variable type is really required.

[luis]

It would be useful to have it, anyway I have some remarks...

Many compilers issue a warning when an unsafe type conversion (where loss of data can happen) take place in the code, like in the examples you posted. That's when casting comes in handy to let know the compiler you know what you are doing. That already helps a lot to spot potential involuntary problems. If we had casting I would be happy with this compiler warning, but we haven't.

I think runtime checks, if needed, could be implemented "manually" by the programmer just in specific portions of code, but I'm always in favor of having something available and maybe not using it most of the times compared to not having it at all.
Like the ASCII builds we used to have.

About the debugger overflow checks

1) it's very time consuming to do that for each and every assignment (may not be a problem in a simple data entry program but it is if you are writing a near real time application and the debugger make it unusable, for example a game). Anyway in some cases, if we had it, I may still use it.

2) overflow may be desired (many checksums, random number generators, and encryption algorithms rely on overflows), so a global overflow check will not cut it in these cases (see 4)

3) being a runtime check, if your code is not deterministic you may not get an overflow in your run but the overflow can happen for the final user under a different scenario, so checking against it with the debugger may not be the best way to detect a possible problem.

4) A possible way to cope with 1) could be to limit runtime overflow checks to specific section of the code by wrapping the section inside a specific keyword pair (EnableOverflowChecks/DisableOverFlowChecks). This would reduce the slowdown but would not solve 3).

I think you may have some remote hope of getting the compiler warning (I have great doubts about the runtime checks), but only if it would be possible to disable it because we don't have casting, so it would complain in every place where you are making a dubious assignment and you woulnd't have a way to cope with it locally driving you mad.

[Derren]

Might be a silly question, but sometimes you just really forget to plug in the device, even if you sometimes wonder how anyone can be this dumb
so: Did you activate the purifier in the options? It's not natively part of the debugger and it's not activated by default.

[luis]

The PB help describes that the purifier of the debugger checks not only memories but also variables, whether the current process reads or writes outside the valid range
...
Looks like the purifier isn't working properly then.

I believe the purify has nothing to do with integer overflows.

It checks if strings, variables, or allocated memory boundaries are overshoot when writing to memory.
So it is working properly accordingly to what specified in the help file:

The purifier detects these errors by placing a special 'salt'-value around global and local variables, strings and allocated memory buffers. These salt values are then checked at regular intervals and an error is displayed if they were changed.

To clarify what it does and what it does not run these examples on x86 with the purifier enabled in compiler options.

Code: Select all

#enable_purifier_checks = 1

CompilerIf #enable_purifier_checks
 PurifierGranularity(0,1,0,0)
CompilerElse
 PurifierGranularity(0,0,0,0)
CompilerEndIf

Procedure foo()
Protected a,b,c

a = 1
b = 2
c = 3

;PokeB(@a+3, $80) ; this is ok, writes inside 'a'
;ShowMemoryViewer(@a,256)

PokeB(@a+4, $80) ; this is not ok, writes outside 'a'
ShowMemoryViewer(@a,256)

Debug a
Debug b
Debug c
EndProcedure

foo()

In this example looking at the output of ShowMemoryViewer() you can actually see the salt values added by the purifier after the four bytes of each integer allocated on the stack.
PokeB(@a+3, $80) works as expected because it is writing inside the boundaries of 'a', changing the value of the integer.



PokeB(@a+4, $80) writes outside and tamper the stacks altering the value of 'b' (if the purifier is disabled). The purifier detects this because its salt is being altered instead.

Code: Select all

Waiting for executable to start...
Executable type: Windows - x86  (32bit, Unicode, Purifier)
Executable started.
[ERROR] Line: 19
[ERROR] Procedure stack has been corrupted.

Same mechanism is used for strings and memory buffers.

Code: Select all

#enable_purifier_checks = 1

CompilerIf #enable_purifier_checks
 PurifierGranularity(0,1,0,0)
CompilerElse
 PurifierGranularity(0,0,0,0)
CompilerEndIf


#MAX_INTEGER = 1 << 31 - 1

Procedure foo()
Protected a,b,c

a = #MAX_INTEGER
Debug a
a = #MAX_INTEGER + 1 ; bits are going to overflow
Debug a

EndProcedure

foo()

This is something the purifier does not care about, all is happening inside the variable's boundaries.
The integer overflow just cause the signed integer to wrap around as expected.

[Sicro]

Did you activate the purifier in the options? It's not natively part of the debugger and it's not activated by default.

Yes

@luis:
Thank you for your explanations!

The purifier detects these errors by placing a special 'salt'-value around global and local variables, strings and allocated memory buffers.

This is something the purifier does not care about, all is happening inside the variable's boundaries.
The integer overflow just cause the signed integer to wrap around as expected.

Okay, so overflows are no problem with integer variables (.b, .w, .l, .q, .a, .u, .i).
In this case the PB help should be adapted, because I understand by "global and local variables" also integer variables.

[luis]

@Sicro

You are welcome, glad it was useful.

Bye