| Author |
Message |
stevech
Joined: 23 Feb 2006
|
|
Posted: 26 February 2006, 4:29 AM Post subject: Integer overflow? |
|
|
I suppose for the sake of speed it's reasonable to ignore errors in a low cost micro like
n = n + 1
where this causes the integral types to wrap to a negative number.
Such as when n is an integer and it reaches 32767.
In a big fat language, you'd get a run-time overflow error. |
|
| Back to top |
|
 |
dkinzer
Site Admin
Joined: 03 Sep 2005
Location: Portland, OR
|
|
Posted: 26 February 2006, 6:46 AM Post subject: |
|
|
This is a run-time issue as opposed to a language issue. And, if such run-time errors were detected, there would need to be some sort of exception handling system to deal with them.
The ZBasic virtual machine has almost no run-time checking except for maximum string length for allocated strings. There is also some checking on arithmetic operations (e.g. divide by zero, square root of a negative, etc.). Other than that, you're on your own. |
|
| Back to top |
|
|
stevech
Joined: 23 Feb 2006
|
|
Posted: 26 February 2006, 6:49 AM Post subject: |
|
|
| makes sense! |
|
| Back to top |
|
|
mikep
Joined: 24 Sep 2005
Location: Austin, TX
|
|
Posted: 26 February 2006, 19:37 PM Post subject: |
|
|
A couple of additonal points on this topic:
1. The following program to increment causes an infinite loop. | Code: | Sub Main()
Dim i as Integer
For i=32760 to 32767
Next
End Sub |
Fortunately the compiler recognizes this condition (and also for a Byte going to 255) and gives you the following warning: | Code: | | test.bas:3: Warning: For loop may never terminate |
2. There is some runtime checking as Don points out. Early on in the Beta I also suggested adding a runtime check for recognizing when the task stack is about to be exceeded as this was a very comon problem in BasicX. See section 3.121 in the documentation: http://www.zbasic.net/doc/ZBasicRef/ZBasicRef63.html. |
|
| Back to top |
|
|
spamiam
Joined: 13 Nov 2005
|
|
Posted: 27 February 2006, 16:58 PM Post subject: |
|
|
While I am in favor of giving me the most raw speed possible, and therefore sacrifice runtime checking, stack checking can solve some really hard-to-diagnose problems that occur intermittently and are hard to reproduce.
As a matter of fact, those exact same symptoms are very probably indicative of a stack overflow.
The problem with detecting the problem during runtime, is what to do with it. It is quite likely that the hardware will be running autonomously, so there is likely not to be any "standard output" to send the report. So, in all likelihood, all the error detection can do is stop the proccessor or create a shut-down condition, which is most likely what will happen anyway (but in an uncontrolled way).
As for bounds checking, I can manage on my own and avoid some major processing overhead! It is ususally clear when I have exceeded the bounds of my variable type.... THis is a problem which I encounter all too frequently. Integer variables can contain some pretty big numbers relatively speaking, but just a could of multiplications and poof you have some REALLY big numbers. The other day, I was checking the bounds of some long math, and I realized that I would be getting an integer 10x larger than any unsigned long! I had to do some not so easy math to figure out how to reduce the magnitude without creating any rounding errors. I finally figured it out. Obvious in retrospect.
I saw an applicable quote: "Inside every big problem is a little problem waiting to be let out!"
-Tony |
|
| Back to top |
|
|
|
