New integer types and promotion rules:

New types:

  __ring(1) etc. up to __ring(64)

Ring types would be specified to behave like abstract algebraic ring of integers congruent size 2^n; such types would behave similarly to the way unsigned types of the same size would behave, except for the following:

1. They would be exempt from integer promotions.  Applying binary operators to a ring of any size and an integer or whole-number type of any size would cause the integer to be converted to the ring type, and would yield a result of the original ring type.  Operations involving two different ring types would be forbidden, except for "&" which would yield a result of the *smaller* ring type.

2. Compilers would be required to allow rings of any size up to the implementation's maximum size, regardless of whether the requested size coincides with any multiple of the machine's word size, and include whatever bit-masking operations are required to yield semantically-correct results.  It would be perfectly acceptable for a compiler to allocate a 32-bit storage word for a __ring(3), but all computations on such rings must yield a result in the range 0-7.

  __whole(1) up to __whole(63)

Whole-number types would be specified to behave like integer types capable of holding values from 0 to 2^n-1; any such types smaller than __int would have computations on them performed using using intermediate values of type __int.  As with ring types, the compiler would be free to allocate as much or as little space to each number as it sees fit.

  __signed(2) up to __signed(64)

Signed-number types would hold values from (2^(n-1)) to (2^(n-1))-1; any such types smaller than __int would have computations on them performed using using intermediate values of type __int.  As with ring types, the compiler would be free to allocate as little or as much space to each number as it sees fit.

Overflow rules:

If a numeric overflow occurs, or an attempt is made to store a value into a storage location (other than a ring) which is too small to hold it, the generated code may cause an immediate trap, or may "store" the value, with the constraint that any future attempt to reading the storage location may arbitrarily trap or yield any number which would be correct modulo 2^(n-1), where n is the specified size of the storage location.

Note that Overflow would no longer constitute "undefined behavior"; among the consequences of this, compilers would no longer be allowed to assume that values upon which computations will be performed cannot cause overflow, but would still be allowed to assume that computations will not yield a result that would be arithmetically impossible.  For example, given:

    int64_t test(int64_t x)
    {
      int temp=(x > 3037000500);
      int64_t y =x*x;
      if (temp) return 1;
      if (y > -3) return 2;      return y;
    }

Under C14 rules, a compiler would be allowed to unconditionally set "temp" to zero, since the only way its value would be non-zero would be if the multiplication was going to overflow and allow the compiler to do whatever it felt like.  Under the proposed rules, such treatment would be forbidden.  The test for "y > -3" would be another story, however; a compiler would be allowed to assume that because the arithmetically-accurately-computed square of any number cannot be negative, there is no way y can be negative and thus no need to test for it.  If an overflow occurs, it would thus be possible for the method to return a negative number.