I'm wrong? you've yourself made a (more complex and intricated) demonstration that this was an additive operation (but using an incremental loop, which is obviously never done like this when these operations can be associated and the number of incremental loops is known from the start).
The only thing ACTUALLY wrong was when you said (INT_MAX - 0 + INT_MIN), which doesn't correlate to anything in the spec or in any implementation. There were also some places where your communication was unclear; it seemed to suggest that you were attributing behaviors to operations that didn't apply.
The CORE of your point was correct, though, and my post was meant not to contradict you there but to try to highlight the specifics of what you were pointing out.
Being an additive operation does not mean it is not "bitwise". But in fact the term "bitwise" you use is the incorrect term, on BCD machines (generally using sign-magnitude) it would be wrong. It's additive yes, but using modular arithmetic (which does not require any loop). All the trick is knowing the (positive) module, which is tied to the signed/unsigned integer "sizes" (i.e. the number of digits it stores, and the base of these digits, which is 2 on all modern machines or 10 on some legacy ones; this "size" is not a number of "char" in C, as returned by the sizeof operator, but is more like the "precision" of floaating point types; it may even be possible that machines will don't use integers at all but floatting point numbers always, in base 2 or 10, with sign and magnitude, or a sign and base-complement representation and still some exponent field in a non-negative range for integers and a rounding operation for the extra precision : in all these possible representations operations do not occur "bitwise" but base-2 operations are emulated to implmeent "~", or "|", or "&", or "^").
No, I was right. You CAN'T make a C-specification-compliant compiler on a BCD architecture or one that exclusively uses IEEE-758 floating point values. (You COULD make one that uses a different internal floating point representation, but the way IEEE-758 works precludes it.) The specification demands certain constraints on what constitutes a valid integer type, and it explicitly calls out that it must be able to represent all 2^n distinct values using n value bits. You can't do this at all in BCD, and IEEE-758 floating point omits the leading 1 i so you don't have distinct representations of 0 and 1 using the value bits alone. It also requires that ~E == max - E if E is of an unsigned type. This means the point is moot: Either your C compiler isn't standards-compliant on those systems, or you have to emulate an acceptable type.
/s/ Adam
