|
- 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.
|
