KiXtart is not strongly typed, so the issue of integer size other than the maximum supported is only of minor interest. Your data and variables will be silently converted by context, which makes setting a type pretty pointless.

For example (ignoring signing for the present), say you have a variable "i" declared as a one byte integer.

In "C":
Code:
i=255+1

"i" now contains zero, as the expression has reached the size of the variable and the extra bits are dropped.

In KiXtart:
Code:
$i=255+1

"$i" now has the value 256. Even worse, it has been converted to a 2 or 4 byte integer so that it is large enough to store the result.

As another example, take a biwise NOT (not to be confused with KiXtarts logical NOT). A bitwise NOT simply reverses all the bits in an expression. Very useful for switching individual bits on and off amongst other things.

The problem is that without being able to assign a size to the expression, you can't determine the size of the result.

Should "NOT 0" be 255, 65535 or 4294967295?

Actually, that last one is even trickier as KiXtart does not support unsigned integers so &FFFFFFFF is "-1", which is a major pain.

The same problem occurs when you want to do a bitwise shift or roll - unless you can fix the size of the expression you are going to have problems, or you are going to have to code around it by explicitly passing the expression size as well as the expression.

There was a recent query on the board about converting a hash key generation algorithm to KiXtart. It is possible, but damned hard in part because of the lack of strongly typed data types.

I particularly miss being able to use unsigned types when it comes to network scripting - it's a bit of a coding nightmare when the values suddenly become negative.

Generally you can code around the problems, but it does make life difficult when trying to convert code from other languages where the (fixed) data size is a part of the coding technique.