Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[kaz@helios.crest.nt.com (Kaz Kylheku)]

In article <01bcea71$74603f40$5e20430c@Rogers>,
James S. Rogers <jimmaureenrogers@worldnet.att.net> wrote:
>Kaz Kylheku <kaz@helios.crest.nt.com> wrote in article 
>> No. What I stated is in the C standard, so it's true for all conforming
>> implementations. It defines the minimum ranges that all arithmetic types
>must
>> have. I wasn't making any claim about the relative sizes of the integral
>types,
>> just repeating the minimum range requirements. 
>
>This is still an interesting answer to the initial question.  What you have
>is not
>a definition of the size of an int, only a definition of its smallest
>possible size.
>So, how big is it, exactly?  You have quoted the C standard which in effect

I don't know! How tall is a tree? ;)

>says that an int is larger than a bread-box, and even describes the size of
>a bread-box.  From this I can logically, and I believe correctly, assume
>that
>a 64 bit int is every bit as conforming as a 32 bit int.

Yes.

>The claim has been made that this produces completely portable code.  This
>claim can be supported only if the programmer is prevented from using any
>int value which cannot be represented by a 32 bit int.  Thus, if a system
>of

That is correct.

>hardware and compiler uses a 64 bit int, only the first 32 bits can ever be
>
>used.  If more than the first 32 bits are used the program, although using
>a

That is true. C89 is effectively a 32 bit language, as far as writing maximally
portable programs goes.

The C9X language will have support for larger integers.

>conforming compiler, will be completely non-portable to a system using a
>32 bit int.

>What does the C standard say about the behavior of an int at the margin of
>its ranges?  Does 1 + INT_MAX always result in INT_MIN?  How about when

Absolutely not! INT_MAX + 1 is an overflow which results in---guess
what---undefined behavior.

>using an unsigned int?  Does 1 + UINT_MAX always result in 0?  If not, then

Only the unsigned types have wrapping properties, thus 1 + UINT_MAX produces
zero, (UINT_MAX is always a Mersenne number).

To simulate modulo 65536 arithmetic in a portable way, you would use the
unsigned int type, and logically AND your results with 65535. If you
don't, you get modulo whatever the implementation gives you.

>what is the portable definition of the behavior of an int at its range
>limits?

If you try to compute an int value that tries to violate the limits, the
behavior is no longer well defined. On two's complement systems, wrapping
occurs. But this is not defined by the language. Correctly written programs
avoid such an error.
 
>Without a well defined set of such conditions no C program could be
>considered portable for its entire range of int values.
>
>Even with such a set of well defined rules, how many C programmers test
>addition, for instance, to determine that X + 1 is greater than X?  Failure

I do not know how many, but I do. In non trivial programs, I use the assert()
facility to detect such errors, ensuring that the preconditions to an operation
are satisfied.

>to
>perform such a test can clearly lead to catastrophic behavior at the limits
>of
>the range of an int.  Your program will then be entirely portable and

Come on, use your imagination. You do not have to perform the test

    assert (x + 1 <= INT_MAX)

in order to satisfy the condition that x is be less than INT_MAX!

You rewrite the test by moving the 1 to the other side of the equation:

    assert (x <= INT_MAX - 1)

In general, the abstract algebraic pre-condition assertions that are written
in the design of a program cannot be directly translated into program
statements because they themselves may violate the constraints of the machine's
arithmetic. However, that doesn't mean that the machine can't be used to test
for these conditions. The tests just have to be rewritten in less
straightforward ways to avoid the overflow.

For example, how would you test whether the sum a + b is within the
range [INT_MAX,INT_MIN], without ever producing an intermediate result that
falls outside of this range?

The solution is to divide into cases. If a and b have opposite sign, then
the result clearly cannot violate the bounds, so no check is required. If a and
b are both negative, then you only need to check that their sum is not below
INT_MIN.  The remaining case, a and b are both positive, is checked against
INT_MAX. The last two cases are rewritten to avoid overflow, of course.

Thus:

    int a, b;

    /*...*/

    if (a > 0 && b > 0) {
	assert(a <= INT_MAX - b);
    } else if (b < 0 && a < 0) {
	assert(a >= INT_MIN - b);
    }

    c = a + b;

This could be written as one big assertion in one line so that it does
not distract the reader of the program.

It's nice to have range-checking built into the language; however, this
does not give you coverage of all conditions, such as loop invariants
or generally andy relationships among variables that are not expressed in the
data declarations. 

I think it's better to learn assertive programming first, and then go to a
language that can do many of the tedious checks for you.
-- 
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
	-- Blair P. Houghton