Arithmetic overflow occurs, for example, when you add 2 numbers together and the answer is a number bigger than the destination variable is capable of storing. For example if the biggest number the variable can store is 255 and you try to add 200 + 60. The mathematical answer is 260 but the variable is only capable of storing a number up to 255.

Why not make the variable capable of storing any number, no matter how large? Unfortunately that is impractical and inefficient in most cases. In some cases it is practical and even desirable, but not usually (and in any event, there is always some maximum limit, even if it is extremely large).

When arithmetic overflow occurs in KL, an overflow error is triggered. And then you (the programmer) can optionally choose to catch the error and respond to it. If you do nothing (you make no attempt to catch the error), then the default response is to display an error message. The program is not terminated, but the remainder of the command where the error occurred is skipped.

C++ compilers usually handle overflow by causing the answer to be silently truncated, meaning some of the higher digits (bits) of the number are chopped off, meaning the calculated answer is mathematically incorrect.

For example, if the computer was based on decimal, and variables could store numbers up to 3 decimal digits (up to 999), and you tried to add 1 to 999, then the mathematically correct answer is ofcourse 1000 but only the lowest 3 digits will be retained (any digits above the lowest 3 will be chopped off), thus the variable is set to 000 (and mathematically-speaking 000 is the same as 0). So you expected an answer of 1000 but without warning you were given an answer of zero. That is how C++ compilers operate. Actually computers use binary not decimal, but the same principles apply.

The problem with handling overflow by silently truncating the answer is that it makes it very easy to make a programming mistake (introduce a bug) that causes the program to malfunction under certain circumstances, or worse creates a security hole.

If you do not care about security, then the way that C++ compilers handle overflow is not much of an issue. But if you do care about security and reliability, it too often causes security holes. Security and reliability is important in Haxial Compiler, thus Haxial Compiler does not handle overflow in the manner of C++ compilers. Haxial Compiler does not produce mathematically incorrect answers in response to arithmetic overflow situations (unless asked to). In Haxial Compiler, instead of a security hole being created, it simply produces an error message.

Occasionally, in certain special situations, the way C++ does it (silent truncation) is actually your desired behavior. In these situations, you can use the "circular add" operation in Haxial Compiler instead of the normal add. "Circular add" produces the same answer as truncation would/does. The "circular add" operation is named as such because it is defined as producing answers that "wrap around" when the maximum number is exceeded (or answers that are modulo the maximum number). According to the definition, there is no possibility of overflow in a "circular add" operation, and thus no overflow error is ever produced by that operation.

It is easy to accidentally create a security hole in C++ without even realizing it, or understanding the situations that lead to security holes (many programmers do not even know that overflow can create security holes). With Haxial Compiler, you are much less likely to create a security hole.