Why doesn't an underflow ( e.g. X *= 0 ) bring down the house ?

Back around 1995, VC's default settings had
a floating-point divide-by-zero would terminate the app.
Even today, an integer divide-by-zero terminates the app.

Why stop the whole show just because an int overflowed ?
How can I turn this " feature " off ?
Why doesn't an underflow ( e.g. X *= 0 ) bring down the house ?

F.Y.I.: For for the 8 bit exponent in VC's â?? float â??,
infinity is 255 ( 2^128, â?? _isnan() == 1 â?? )
and zero is zero ( notionally 2^-127, provided: â?? _clearfp() == 0 â?? ).

The largest " true " float is 2^128 - 1 ( FLT_MAX )
and the smallest is 2^-126 ( FLT_MIN ).

Carl
Thu Jul 26 10:12:45 CDT 2007

Jeff?Relf wrote:
> Back around 1995, VC's default settings had
> a floating-point divide-by-zero would terminate the app.
> Even today, an integer divide-by-zero terminates the app.
>
> Why stop the whole show just because an int overflowed ?

Divide by zero isn't overflow; it's an operation with an undefined result.

The "whole show" isn't stopped in any case. An exception is raised by the
hardware, converted to a structured exception by the kernel. You can
prevent program termination by handling the exception.

> How can I turn this " feature " off ?

You can't. Handle the exception.

> Why doesn't an underflow ( e.g. X *= 0 ) bring down the house ?

That's not underflow, it's a valid mathematical operation with a
well-defined result exactly representable as any numeric type.

-cd

Jeff_Relf
Thu Jul 26 11:19:20 CDT 2007

Zero is below 2^-126 ( FLT_MIN ), Carl_Daniel.

As I said, the 8-bit exponednt of a â?? float â??
can represent infinity... it's just 255, the overflow.
zero is zero, the underflow, below 2^-126 ( FLT_MIN ).

So I don't see why and exception should be raised,
bringing down everyone's app, just because of an overflow
( and not when there's an underflow, e.g. X *= 0 ).

â?? _control87( _MCW_EM , _MCW_EM ) â?? turns off
all FPU â?? Interrupt exceptions â??.
Today, one doesn't have to do this, it's just the default.

Isn't there a way to do the same for integers ?
If not, what do I have to do to handle these exceptions ?

Eberhard
Thu Jul 26 12:26:24 CDT 2007

Jeffâ? Relf schrieb/wrote:

> So I don't see why and exception should be raised,
> bringing down everyone's app, just because of an overflow

As Carl already indicated, the mathematical result of a division by zero
is as much an overflow as it is an underflow or 0 or 1 or 42. It is an
operation that does not make sense. There can be no "correct" result for
this operation, not even over- or underflow. What the IEEE floating
point standard specifies as result(s) is just a convention. The
convention under Windows for its Two's Complement arithmetic is to throw
a Structured Exception, and VC simply does nothing in particular to
change that behaviour.

So you have to live with the convention. Here that means catching the
Structured Exception using __try/__catch, or avoiding the case
altogether by ensuring that the divisor does not equal 0.

> ( and not when there's an underflow, e.g. X *= 0 ).

I don't see why you keep bringing this up. "x * 0" is perfectly well
defined for rational and integer numbers, and yields 0. That is the
precise result of the operation, not an underflow. Or is "3 - 3" an
underflow?

Jeff_Relf
Thu Jul 26 14:03:31 CDT 2007

You ( Eberhard ) asked me: â?? is "3 - 3" an underflow ? â??.

Because there's no way to fully represent the number 10.0, for example,
calculations often result in non-zero, denormalized numbers,
i.e. below â?? FLT_MIN = 2^-126 â?? with â?? _clearfp() != 0 â??.

Like zero itself, a divide by zero is defined... it's infinity.
An 8-bit exponent set to 255 would indicate 2^128
if the FPU hadn't reserved it for the overflow indicator.

Hence: â?? FLT_MAX = 2^128 - 1 â??.

Likewise, a zeroed 8-bit exponent would indicate 2^-127 ( an underflow )
if the FPU hadn't reserved it for the zero ( or denormalized ) indicator.

Hence: â?? FLT_MIN = 2^-126 â??.

As for integers... Placing â?? __try/__catch â?? combos everywhere
is not an acceptable workaround.

If there's not something like â?? _control87( _MCW_EM , _MCW_EM ) â??
I just won't worry about it... thanks anyway.

Jeff_Relf
Thu Jul 26 17:31:16 CDT 2007

Oops, I should've said:
â?? There's no way to fully represent the number â?? .1 â??. â??.

The following shows how innocent looking math can produce NaN's:

#pragma warning( disable: 4007 4189 4305 4430 4508 )
#include <Float.H>
WinMain( int, int, int, int ) { int X ;
float DeNormal = ( .1 - .09 - .01 ) / 1e22 ;
X = * ( int * ) & DeNormal ;
// Now, â?? DeNormal == 8.674e-040 â??, â?? X == 0x7f800000 â??.
// and â?? _clearfp() != 0 â??.
float NaN = ! DeNormal ? 0 : 1 / DeNormal ; X = * ( int * ) & NaN ;
// Now, â?? _isnan( NaN ) == 1 â?? and â?? X == 0x7f800000 â??
float Zero
= ( _clearfp(), ! DeNormal || _clearfp() ) ? 0 : 1 / DeNormal ;
} // The first _clearfp() is required because the state lingers.
// â?? Zero == 0 â??.

Jeff_Relf
Thu Jul 26 17:48:04 CDT 2007

Oops, I should've said:

// Now, â?? DeNormal == 8.674e-040 â??, â?? X == 0x000971da â??.
// and â?? _clearfp() != 0 â??.

Tim
Fri Jul 27 23:29:50 CDT 2007

Jeff?Relf <Jeff_Relf@Yahoo.COM> wrote:
>
>The largest " true " float is 2^128 - 1 ( FLT_MAX )
>and the smallest is 2^-126 ( FLT_MIN ).

No, that's the smallest float greater than zero. Zero is a perfectly valid
floating point value.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Tim
Fri Jul 27 23:41:04 CDT 2007

Jeff?Relf <Jeff_Relf@Yahoo.COM> wrote:

>You ( Eberhard ) asked me: ? is "3 - 3" an underflow ? ?.
>
>Because there's no way to fully represent the number 10.0,

Of course there is! 10.0 can be represented exactly in IEEE floating
point, as can all integers less than FLT_MAX. 0.1 cannot, but 10.0
certainly can (as can 0.5 and 0.25).

>As for integers... Placing ? __try/__catch ? combos everywhere
>is not an acceptable workaround.

In that case, you just need to check the divisor for zero before each
division.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Ben
Sat Jul 28 14:15:33 CDT 2007


"Tim Roberts" <timr@probo.com> wrote in message
news:qihla3l4g6mr6c5obok287h1qnd58kkdtt@4ax.com...
> Jeff?Relf <Jeff_Relf@Yahoo.COM> wrote:
>
>>You ( Eberhard ) asked me: " is "3 - 3" an underflow ? ".
>>
>>Because there's no way to fully represent the number 10.0,
>
> Of course there is! 10.0 can be represented exactly in IEEE floating
> point, as can all integers less than FLT_MAX. 0.1 cannot, but 10.0

Nonsense. 1e30 is less than FLT_MAX, and 1e30 and (1e30 - 1) are both
integers, but a float can't distinguish between them, there aren't enough
significant digits.

> certainly can (as can 0.5 and 0.25).
>
>>As for integers... Placing " __try/__catch " combos everywhere
>>is not an acceptable workaround.
>
> In that case, you just need to check the divisor for zero before each
> division.
> --
> Tim Roberts, timr@probo.com
> Providenza & Boekelheide, Inc.

Jeff_Relf
Sat Jul 28 16:22:30 CDT 2007

In â?? news:Jeff_Relf_2007_Jul_26__3_31_PP@Cotse.NET â?? I correcte myself:
â?? Oops, I should've said:
â?? There's no way to fully represent the number â?? .1 â?? . â??. â??.

In â?? news:Jeff_Relf_2007_Jul_26__0_3_Pe@Cotse.NET â?? I already decided:
â?? If there's not something like â?? _control87( _MCW_EM , _MCW_EM ) â??
I just won't worry about it... thanks anyway. â??

Tell me why an integer overflow should crash my show, god damn it !
I'd really love to know. Why yer at it, tell me why an underflow,
e.g. zero, doesn't do the same thing.

As I said in â?? news:Jeff_Relf_2007_Jul_26__6_5_PJ@Cotse.NET â??...

NaN's ( i.e. overflows ) are the inverse of denormals ( underflows ).
Why overflowes crashed ( i.e. an 8 bit exponent of 255 )
and not underflows ( i.e. an exponent of 0 ), I'll never know.

Here's an even simpler example of how to get a NaN:
â?? #pragma warning( disable: 4007 4189 4430 4508 )
#include <Math.H>
WinMain( int, int, int, int ) {
float Sum = .1 - .09 - .01, NaN = ! Sum ? 0 : pow( Sum, -3 );
} â??.

Tim
Sun Jul 29 23:13:56 CDT 2007

"Ben Voigt [C++ MVP]" <rbv@nospam.nospam> wrote:
>
>"Tim Roberts" <timr@probo.com> wrote in message
>news:qihla3l4g6mr6c5obok287h1qnd58kkdtt@4ax.com...
>> Jeff?Relf <Jeff_Relf@Yahoo.COM> wrote:
>>
>>>You ( Eberhard ) asked me: " is "3 - 3" an underflow ? ".
>>>
>>>Because there's no way to fully represent the number 10.0,
>>
>> Of course there is! 10.0 can be represented exactly in IEEE floating
>> point, as can all integers less than FLT_MAX. 0.1 cannot, but 10.0
>
>Nonsense. 1e30 is less than FLT_MAX, and 1e30 and (1e30 - 1) are both
>integers, but a float can't distinguish between them, there aren't enough
>significant digits.

Yes, of course, that was silly of me. "All integers less than 1 <<
FLT_MANT_DIG" is the sentiment I intended to express.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Jag
Tue Jul 31 10:05:22 CDT 2007

>
> > How can I turn this " feature " off ?
>
> You can't. Handle the exception.
>

Why not use __try ... __except ?
---Jag

Ben
Wed Aug 01 16:45:35 CDT 2007

> Tell me why an integer overflow should crash my show, god damn it !
> I'd really love to know. Why yer at it, tell me why an underflow,
> e.g. zero, doesn't do the same thing.

Neither integer overflow nor underflow crash. This is overflow:

unsigned u = ~0; // a very very big number
++u; // overflowed to zero

There is no crash.

This is also overflow:

unsigned u = ~0;
u *= 25;

Again, no crash.

Victor
Wed Aug 01 17:35:41 CDT 2007

Ben Voigt [C++ MVP] wrote:
>> Tell me why an integer overflow should crash my show, god damn it !
>> I'd really love to know. Why yer at it, tell me why an underflow,
>> e.g. zero, doesn't do the same thing.
>
> Neither integer overflow nor underflow crash. This is overflow:
>
> unsigned u = ~0; // a very very big number
> ++u; // overflowed to zero

No, it isn't, at least in C++. Operations on 'unsigned int' are
different from operations on 'int'. The result of arithmetic ops
for 'unsigned' are always mod 2^n where 'n' is the number of bits
in the representation (see [basic.fundamental]/4 and the footnote).
Same operations on 'int' can have undefined behaviour (please see
[expr]/5), but I don't recall seeing any particular explanation
in VC++ help or anywhere else. A note in the Standard even says
"most existing implementations of C++ ignore integer overflows".

> There is no crash.
>
> This is also overflow:
>
> unsigned u = ~0;
> u *= 25;

No, it is not. Change 'u' to 'int', then it may be.

> Again, no crash.

Undefined behaviour is undefined behaviour.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Ben
Thu Aug 02 08:28:03 CDT 2007


"Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
news:f8r1rt$ser$1@news.datemas.de...
> Ben Voigt [C++ MVP] wrote:
>>> Tell me why an integer overflow should crash my show, god damn it !
>>> I'd really love to know. Why yer at it, tell me why an underflow,
>>> e.g. zero, doesn't do the same thing.
>>
>> Neither integer overflow nor underflow crash. This is overflow:
>>
>> unsigned u = ~0; // a very very big number
>> ++u; // overflowed to zero
>
> No, it isn't, at least in C++. Operations on 'unsigned int' are
> different from operations on 'int'. The result of arithmetic ops
> for 'unsigned' are always mod 2^n where 'n' is the number of bits
> in the representation (see [basic.fundamental]/4 and the footnote).

That doesn't mean it isn't overflow. It means that behavior during overflow
is well documented.

> Same operations on 'int' can have undefined behaviour (please see
> [expr]/5), but I don't recall seeing any particular explanation
> in VC++ help or anywhere else. A note in the Standard even says
> "most existing implementations of C++ ignore integer overflows".
>
>> There is no crash.
>>
>> This is also overflow:
>>
>> unsigned u = ~0;
>> u *= 25;
>
> No, it is not. Change 'u' to 'int', then it may be.

Your assertion that this is not integer overflow doesn't make it not integer
overflow. It is integer overflow of an unsigned type, and the results are
well-defined, but not "correct" in a mathematical sense, leading to the
well-known category of integer overflow attacks in computer security.

i.e. creating an vector of type long and length (MAX_PTR/4 + 1) is a good
way to bypass subscript checking in a lot of vector implementations, because
you end up allocating just one long, but subscripting anywhere in system
memory.

Victor
Thu Aug 02 08:34:06 CDT 2007

Ben Voigt [C++ MVP] wrote:
> "Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
> news:f8r1rt$ser$1@news.datemas.de...
>> Ben Voigt [C++ MVP] wrote:
>>>> Tell me why an integer overflow should crash my show, god damn it !
>>>> I'd really love to know. Why yer at it, tell me why an underflow,
>>>> e.g. zero, doesn't do the same thing.
>>>
>>> Neither integer overflow nor underflow crash. This is overflow:
>>>
>>> unsigned u = ~0; // a very very big number
>>> ++u; // overflowed to zero
>>
>> No, it isn't, at least in C++. Operations on 'unsigned int' are
>> different from operations on 'int'. The result of arithmetic ops
>> for 'unsigned' are always mod 2^n where 'n' is the number of bits
>> in the representation (see [basic.fundamental]/4 and the footnote).
>
> That doesn't mean it isn't overflow. It means that behavior during
> overflow is well documented.

Yes, it does mean "no overflow". The footnote 41 in the Standard
circa 2003 says "This implies that unsigned arithmetic does not
overflow because ...". I read it as "unsigned arithmetic does NOT
overflow". To me it means "no overflow". Am I missing something?

> [..]

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Alexander
Thu Aug 02 08:47:45 CDT 2007

Maybe it's time for you to study "IEC 60559 floating-point arithmetic"
standard and stop being obsessed about zero. And also study ISO:IEC9899 C
standard and find out when _integer_ overflow can cause an exception
(answer, only in signed arithmetics, non-specified by the standard). In most
environments integer overflow is not causing any exception.

"Jeff?Relf" <Jeff_Relf@Yahoo.COM> wrote in message
news:Jeff_Relf_2007_Jul_28__2_22_Pe@Cotse.NET...
> In " news:Jeff_Relf_2007_Jul_26__3_31_PP@Cotse.NET " I correcte myself:
> " Oops, I should've said:
> ' There's no way to fully represent the number ? .1 ? . '. ".
>
> In " news:Jeff_Relf_2007_Jul_26__0_3_Pe@Cotse.NET " I already decided:
> " If there's not something like ' _control87( _MCW_EM , _MCW_EM ) '
> I just won't worry about it... thanks anyway. "
>
> Tell me why an integer overflow should crash my show, god damn it !
> I'd really love to know. Why yer at it, tell me why an underflow,
> e.g. zero, doesn't do the same thing.
>
> As I said in " news:Jeff_Relf_2007_Jul_26__6_5_PJ@Cotse.NET "...
>
> NaN's ( i.e. overflows ) are the inverse of denormals ( underflows ).
> Why overflowes crashed ( i.e. an 8 bit exponent of 255 )
> and not underflows ( i.e. an exponent of 0 ), I'll never know.
>
> Here's an even simpler example of how to get a NaN:
> " #pragma warning( disable: 4007 4189 4430 4508 )
> #include <Math.H>
> WinMain( int, int, int, int ) {
> float Sum = .1 - .09 - .01, NaN = ! Sum ? 0 : pow( Sum, -3 );
> } ".
>

Ben
Thu Aug 02 12:55:23 CDT 2007


"Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
news:f8smgd$5p9$1@news.datemas.de...
> Ben Voigt [C++ MVP] wrote:
>> "Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
>> news:f8r1rt$ser$1@news.datemas.de...
>>> Ben Voigt [C++ MVP] wrote:
>>>>> Tell me why an integer overflow should crash my show, god damn it !
>>>>> I'd really love to know. Why yer at it, tell me why an underflow,
>>>>> e.g. zero, doesn't do the same thing.
>>>>
>>>> Neither integer overflow nor underflow crash. This is overflow:
>>>>
>>>> unsigned u = ~0; // a very very big number
>>>> ++u; // overflowed to zero
>>>
>>> No, it isn't, at least in C++. Operations on 'unsigned int' are
>>> different from operations on 'int'. The result of arithmetic ops
>>> for 'unsigned' are always mod 2^n where 'n' is the number of bits
>>> in the representation (see [basic.fundamental]/4 and the footnote).
>>
>> That doesn't mean it isn't overflow. It means that behavior during
>> overflow is well documented.
>
> Yes, it does mean "no overflow". The footnote 41 in the Standard
> circa 2003 says "This implies that unsigned arithmetic does not
> overflow because ...". I read it as "unsigned arithmetic does NOT
> overflow". To me it means "no overflow". Am I missing something?

I don't know. I would have phrased that more like "unsigned arithmetic
overflow is not exceptional".

This is getting kinda Kerry-esque: it overflowed before it didn't overflow.
The operation overflowed, wrapping around and producing a result in the
range of the variable. Since the result is in range, there is no overflow.

Certainly a lot of the "integer overflow" class of attacks occur with
unsigned types. Also I believe that the "carry/overflow" bit will be set in
the CPU for most any instruction set following that statement.

Victor
Fri Aug 03 20:07:36 CDT 2007

Ben Voigt [C++ MVP] wrote:
> "Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
> news:f8smgd$5p9$1@news.datemas.de...
>> Ben Voigt [C++ MVP] wrote:
>>> "Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
>>> news:f8r1rt$ser$1@news.datemas.de...
>>>> Ben Voigt [C++ MVP] wrote:
>>>>>> Tell me why an integer overflow should crash my show, god damn
>>>>>> it ! I'd really love to know. Why yer at it, tell me why an
>>>>>> underflow, e.g. zero, doesn't do the same thing.
>>>>>
>>>>> Neither integer overflow nor underflow crash. This is overflow:
>>>>>
>>>>> unsigned u = ~0; // a very very big number
>>>>> ++u; // overflowed to zero
>>>>
>>>> No, it isn't, at least in C++. Operations on 'unsigned int' are
>>>> different from operations on 'int'. The result of arithmetic ops
>>>> for 'unsigned' are always mod 2^n where 'n' is the number of bits
>>>> in the representation (see [basic.fundamental]/4 and the footnote).
>>>
>>> That doesn't mean it isn't overflow. It means that behavior during
>>> overflow is well documented.
>>
>> Yes, it does mean "no overflow". The footnote 41 in the Standard
>> circa 2003 says "This implies that unsigned arithmetic does not
>> overflow because ...". I read it as "unsigned arithmetic does NOT
>> overflow". To me it means "no overflow". Am I missing something?
>
> I don't know. I would have phrased that more like "unsigned
> arithmetic overflow is not exceptional".
>
> This is getting kinda Kerry-esque: it overflowed before it didn't
> overflow. The operation overflowed, wrapping around and producing a
> result in the range of the variable. Since the result is in range,
> there is no overflow.
> Certainly a lot of the "integer overflow" class of attacks occur with
> unsigned types. Also I believe that the "carry/overflow" bit will be
> set in the CPU for most any instruction set following that statement.

Yes, the carry bit is set. The emitted code doesn't care about it and
there is no way except inline assembly to actually get at it, and I do
not know a reliable way to do so, either.

bool overflowed(unsigned a, unsigned b)
{
bool rv = false;
unsigned ab = a + b;
__asm {
jnc nocarry
mov rv, 1
nocarry:
}
return rv;
}

int main()
{
bool should = overflowed(-1, 2);
bool shouldnot = overflowed(1, 2);
return should + shouldnot;
}

This does work correctly built in debug mode, but fails in release,
which is not unexpected.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask