Undefined Behavior
 ------------------
 In the C language, some operations are undefined, like signed integer overflow,
 dereferencing freed pointers, accessing outside allocated space, ...
 
 Undefined Behavior must not occur in a C program, it is not safe even if the
 output of undefined operations is unused. The unsafety may seem nit picking
 but Optimizing compilers have in fact optimized code on the assumption that
 no undefined Behavior occurs.
 Optimizing code based on wrong assumptions can and has in some cases lead to
 effects beyond the output of computations.
 
 
 The signed integer overflow problem in speed critical code
 ----------------------------------------------------------
 Code which is highly optimized and works with signed integers sometimes has the
 problem that some (invalid) inputs can trigger overflows (undefined behavior).
 In these cases, often the output of the computation does not matter (as it is
 from invalid input).
 In some cases the input can be checked easily in others checking the input is
 computationally too intensive.
 In these remaining cases a unsigned type can be used instead of a signed type.
 unsigned overflows are defined in C.
 
 SUINT
 -----
 As we have above established there is a need to use "unsigned" sometimes in
 computations which work with signed integers (which overflow).
 Using "unsigned" for signed integers has the very significant potential to
 cause confusion
 as in
 unsigned a,b,c;
 ...
 a+b*c;
 The reader does not expect b to be semantically -5 here and if the code is
 changed by maybe adding a cast, a division or other the signedness will almost
 certainly be mistaken.
 To avoid this confusion a new type was introduced, "SUINT" is the C "unsigned"
 type but it holds a signed "int".
 to use the same example
 SUINT a,b,c;
 ...
 a+b*c;
 here the reader knows that a,b,c are meant to be signed integers but for C
 standard compliance / to avoid undefined behavior they are stored in unsigned
 ints.