🚀 go-pugleaf

I recently read the SBEIR proposal for extended integers in C and
offer my comments.  Some concerns may reflect my misreading or
overlooking part of the proposal.  

Copies can be obtained at 
ftp://ftp.dmk.com.DMK/sc22wg14/c9x/extended-integers/sbeir.*.
===================================================================

Comments on SBEIR Proposal for Standard C: C9X Specification-Based
Extended Integer Range Draft 2 (5.1), by Frank Farance and William
Rugolsky, Jr.

General Impression
------------------
I believe that the concept presented can aid in writing portable
programs, especially those with concerns for optimization.  Further,
usage of exact precision can simplify some coding by eliminating masking
operations, thereby reducing programming and debugging time. Users
should beware, however, of the additional hidden cost of exact
precision, especially those sizes that do not correspond to a natural
size in the target architecture.

The following comments concern mostly the details of the proposal and
not the fundamental concept.

Specified precision of expression
---------------------------------
The SBEIR proposal determines, for an integral expression, a
specified precision attribute.  Although it may be useful to query
the specified precision of a declared integral object, the type of an
expression has no actually specified precision (it may be cast to a
specified precision, however).  I see no utility to assigning a
specified precision to an integral expression.  The only place that
carrying a separate specified precision seems to makes a difference
to arithmetic in the proposal is determining whether a converted
operand is signed or unsigned in the new rule for usual arithmetic
conversions, which is now considered.

The rule for determining the sign of a promoted operand, given one
signed and one unsigned operand, according to the proposed usual
arithmetic conversions, compares first the actual precision of the
operands, then if they are the same, the specified precision of the
operands.  If the specified precisions are different, the signedness of
the operand with the larger specified precision is the signedness of the
result (and implicitly the sign of the converted operands prior to a
binary operation), otherwise the result is unsigned.  This can give a
different result from the existing rules in the following example:

    Assume the following standard type mapping:

    typedef signed fast int atleast:32 int;  /* example given */
    typedef signed      int exact  :64 long; /* for 64-bit machine */

    Then assume that the system maps int to an actual precision of 64
    bits.  Consider the code

        unsigned int a;
        long int b;
        unsigned long c;
        ...
        c = (b+a);

    In Standard C, if both ints and long ints are 64 bits, the
    expression (c+a) has type unsigned long int.  In the SBEIR proposal,
    the expression (c+a) has type signed atleast:64 int.  The Standard C
    interpretation is thus well-defined, while the SBEIR proposal can
    invoke undefined behavior on overflow for the same expression.

    I recommend dropping specified precision as an attribute of an
    integral expression.

Integral Promotions
-------------------
In Standard C, types char, short int, or int bit-field, or signed or
unsigned varieties undergo integral promotion to int or unsigned int.
The SBEIR proposal discusses this briefly in section 2.2.2, but doesn't
specify whether the promotion is to unoptimized int, fast int, or
small int.  Is it always unoptimized int or does the specified
optimization of the original type get inherited?  The proposal also does
not add any words to the standard section on integral promotions to deal
with extended ints.

Default precision mapping of signed and unsigned types
------------------------------------------------------
The SBEIR doesn't clearly address the issue of whether a single mapping
is made for both signed and unsigned varieties of standard int types, or
whether different mappings are possible for signed vs. unsigned, e.g.,
can int be mapped to a different precision than unsigned int?  Standard
C requires that they have the same precision, but it is not clear
whether the SBEIR does.

Largest integral type
---------------------
The largest integral type in Standard C is long int and unsigned long
int.  The proposal apparently allows specification of integral types
larger than long int.  There is no designation for the largest integral
type supported, which gives problems when a universal int is desired.
An example is integer constants.  What is the type of an integer
constant that exceeds unsigned long?  This is needed for determining the
data type to be passed as an argument to a non-prototyped function.

Preprocessor constant expressions
---------------------------------
Currently, preprocessor constant expressions are evaluated as long or
unsigned long.  In the SBEIR proposal, there may be larger types than
long, so it seems desirable to process expressions in the largest
supported integer type.  This is another aspect of the largest integral
type issue mentioned previously.

Standard functions for larger data types
----------------------------------------
If long int is no longer the largest integral type, functions
corresponding to labs and ldiv should be provided for larger types.

Thad