signed integer overflow

[REH]

If the is_modulo field of the numeric_limits class is true for signed
integer types, can I assume that overflow for such types is defined
behavior? If so, is the behavior the same regardless of
implementation?

Also, if the range of an integer type is not symmetrical around zero
(i.e., 2's comp.), is it safe to assume that the extra value(s) is one
the negative side?

Thanks,

REH

 

[Jack Klein]

If the is_modulo field of the numeric_limits class is true for signed
integer types, can I assume that overflow for such types is defined
behavior? If so, is the behavior the same regardless of
implementation?

I'd suggest asking this one in comp.std.c for a definitive answer, but
I would say no. That is, if is_modulo can be true for a signed
integer type. I can't find anything in the standard that says either
way.

Not undefined in the sense that it will explode, but in the sense that
there is no definitive answer.

If you perform arithmetic on unsigned types that over- or underflows,
the result is well-defined and exact. If you perform arithmetic on
signed integer types that does not over- or underflow, the result is
well-defined.

But let's take a platform with 16 bit ints (to keep the numbers
small), and let's assume that the bits of the result are the same as
if the values were unsigned types.

If you add 0x7FFF and 0x0001, values of 32767 and 1, and the adder
produces 0x8000, what is the value? On a signed-magnitude
representation, this is -0. On a 1's complement platform, it is
-32767. And on a 2's complement platform it would be -32768.

Since there is no unique answer, and it is not specifically stated in
the standard that it is implementation-defined or unspecified, that
pretty much makes it undefined in that sense.

Also, if the range of an integer type is not symmetrical around zero
(i.e., 2's comp.), is it safe to assume that the extra value(s) is one
the negative side?

Unfortunately the C++ standard is not as specific about the details of
how negative integer values are represented as is the 1999 C standard.
But given that the C++ standard specifically states, as the C standard
does, that it allows exactly three types of representation, and 2's
complement is the only one of the three that can be unsymmetrical, the
fact is that there is one and only one "unmatched" value, and it is
indeed on the negative side.

 

[REH]

I'd suggest asking this one in comp.std.c for a definitive answer, but
I would say no. That is, if is_modulo can be true for a signed
integer type. I can't find anything in the standard that says either
way.

Thanks, Jack. The reasons I asked here are:
1) I am using C++, and I thought (I guess incorrectly), that the two
languages differed slightly in their dealings with signed/unsigned values.
I am writing a class template to behave like Ada's ranged types (and
subtypes). Checking that a value is within range is, of course, simplistic
as is detecting overflow with unsigned types. I'm fining handling signed
types without deveating from the standard or making assumptions about
implemenation, difficult. I am attempting to "catch" the overflow before it
occurrs, so I do not have to stray into the realm of undefined behavior. My
current thinking is to do all the math with unsigned quantities, check for
overflow, then fixup the sign afterwards. I thought I'd deal with the
non-symmectric around zero problem as a corner case.
2) In trying to research the answer before bothering you folks, I noticed
that on the 2's comp. implementations I use, that some have the is_modulo
field of the std::numeric_limits template class set to true for int. I was
hoping this was an indication that they behaved as unsigned type when
dealing with rollover.

But I will rephrase my question in C terms and ask on that group.

Unfortunately the C++ standard is not as specific about the details of
how negative integer values are represented as is the 1999 C standard.
But given that the C++ standard specifically states, as the C standard
does, that it allows exactly three types of representation, and 2's
complement is the only one of the three that can be unsymmetrical, the
fact is that there is one and only one "unmatched" value, and it is
indeed on the negative side.

I did not realize that the standard allowed only three representations. If
that is true, then I think I'm fine (programmatically, anyways!). I was
worried about my code working correctly on some strange format I've never
heard of. I believe it is correct for 1's comp., 2's comp., and sign/mag.
formats.

I do try consulting the Standard before asking, but I find it hard to
comprehend sometimes. That should not be taken as a slight against the
hardworking people who wrote it. I've always had problems reading documents
that have to be written in exacting terms (software licenses, contacts,
etc., give me similar problems).

REH