1) It's not UB. Underflow is defined for unsigned integers (wrap around), and there's no underflow for signed integers.
2) However, that doesn't mean you can ignore over/underflow for signed integers in general. There are platforms that trap on overflow. There may also be platforms that have an integer NaN they'd use for overflow results. And if that's the case, the claim that the subtraction will produce SOME result is, well, only half-true. Operations on NaNs usually have weird results.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
VAX with the IV status bit set.
http://h71000.www7.hp.com/doc/73fina...15pro_014.html
CLR in checked mode.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Short story:
It's impossible to truly determine that.
Wether singed or unsigned, the var is still meerly a specified amount of reserved memory. Being singed or unsigned only changes the behavior of the compiler's operations on that varible. That's all.
The behaviour is defined in in paragraph 2 of section 4.7 of the 2003 edition of the C++ Standard (ISO/IEC 14882:2003).Can you direct me to the relevant section(s)? I'm having difficulty locating it.
If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source integer (modulo 2 n where n is the number of bits used to represent the unsigned type). [Note: In a two's complement representation, this conversion is conceptual and there is no change in the bit pattern (if there is no truncation). ]
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Thanks laserlight.
Apologies, brewbuck.