19

Possible Duplicate:
Value returning 1.#INF000

I always thought division by 0 would result in a compiled program crashing

However I discovered today (using VC++ 2010 Express) that division by 0 gives something called 1.#INF000 and it is supposed to be positive infinity

When it was passed to a function, it got passed as -1.#IND000

What is this all about?

Searching 1.#INF000 and -1.#IND000 on google do not provide any clear explanations either

Is it just something specific to VC++ ?

Community
  • 1
  • 1
user13267
  • 6,871
  • 28
  • 80
  • 138
  • http://stackoverflow.com/questions/8488841/value-returning-1-inf000 – vinayr Sep 27 '12 at 08:46
  • 3
    `1.#IND000` is the representation of `NaN` AFAIK. – nneonneo Sep 27 '12 at 08:48
  • @nneonneo http://stackoverflow.com/questions/9883128/what-does-1-ind000-mean-in-visual-studio-debug-window – Will Sep 27 '12 at 08:58
  • @Will there was nothing in the question that suggested the division is of a floating point. – Luchian Grigore Sep 27 '12 at 09:06
  • 5
    I thought the fact that the result was 1.#INF000, a floating point value, would imply the division was floating point. Otherwise it would be an undefined integer value surely? – Will Sep 27 '12 at 09:11
  • @Will if the behavior is undefined, any value is valid without any implications on the types of the operands. And in this case it is. It makes no difference whether the right operand is int of float. – Luchian Grigore Sep 27 '12 at 09:38
  • 2
    `1,#INF000` and `1.#IND000` is __not__ legal representations of anything. The standard requires `Inf` or `Infinity` for infinity, and `Nan` for not a number (supposing, of course, the implementation supports these values). This is a serious bug in VC++, and causes no end of problems (especially because no other program will read them back as infinity or not a number). – James Kanze Sep 27 '12 at 09:38
  • When in doubt, use an `int`. You're much more likely to get a satisfying crash. –  Apr 14 '14 at 21:25

4 Answers4

25

Floating point division by zero behaves differently than integer division by zero.

The IEEE floating point standard differentiates between +inf and -inf, while integers cannot store infinity. Integer division by zero results in undefined behaviour. Floating point division by zero is defined by the floating point standard and results in +inf or -inf.

Edit:

As pointed out by Luchian, C++ implementations are not required to follow the IEEE Floating point standard. If the implementation you use doesn't follow the IEEE Floating point standard the result of floating point division by zero is undefined.

Klas Lindbäck
  • 33,105
  • 5
  • 57
  • 82
  • 1
    C++ is described by the C++ standard. – Luchian Grigore Sep 27 '12 at 09:00
  • 2
    Ironically, under default settings, processes in Linux get a SIGFPE ("floating point exception") for dividing integers by zero, but not dividing floats by zero... – nneonneo Sep 27 '12 at 09:03
  • The result is NaN if the dividend is zero. – ouah Sep 27 '12 at 09:04
  • @nneonneo but the code is `FPE_INTDIV` for *integer division by zero*. – ouah Sep 27 '12 at 09:05
  • Yes, I know, but it's still funny (to me, maybe). – nneonneo Sep 27 '12 at 09:06
  • 1
    @LuchianGrigore in what is this answer wrong? – ouah Sep 27 '12 at 09:08
  • 1
    @ouah the result is undefined. The behavior is undefined. – Luchian Grigore Sep 27 '12 at 09:09
  • @iammilind Why is this answer correct? – Luchian Grigore Sep 27 '12 at 09:20
  • 6
    @LuchianGrigore: if `std::numeric_limits::is_iec559` is true, then the `double` behavior must follow IEEE 754 rules. all the machinery that is there for checking e.g. NaN (in C++11), would be meaningless if not for this. so there's a **defect** in the standard regarding the wording about "undefined" behavior. because UB in standardese means no requirements on an implementation, while later on the standard does impose such requirements (conditionally). – Cheers and hth. - Alf Sep 27 '12 at 09:40
  • @Cheersandhth.-Alf regardless, this answer is not conditioned by this, as it is now. Still wrong. – Luchian Grigore Sep 27 '12 at 09:43
  • 1
    @LuchianGrigore: That an answer is incomplete does not make it wrong. I think OP was looking for an explanation for the observed behaviour, not lawyering about standards. – Joren Sep 27 '12 at 13:36
  • @Joren if the level of incompleteness affect its validity, sure it does. (didn't see the edit until now) – Luchian Grigore Sep 27 '12 at 13:38
12

Edit: The question is about C++ and the result in C++ is undefined, as clearly stated by the standard, not the IEEE or whatever other entity that doesn't, in fact, regulate the C++ language. The standard does. C++ implementations might follow IEEE rules, but in this case it's clear the behavior is undefined.

I always thought division by 0 would result in a compiled program crashing

Nope, it results in undefined behavior. Anything can happen, a crash is not guaranteed.

According to the C++ Standard:

5.6 Multiplicative operators

4) The binary / operator yields the quotient, and the binary % operator yields the remainder from the division of the first expression by the second. If the second operand of / or % is zero the behavior is undefined; otherwise (a/b)*b + a%b is equal to a. If both operands are nonnegative then the remainder is nonnegative; if not, the sign of the remainder is implementation-defined79). (emphasis mine)

Luchian Grigore
  • 253,575
  • 64
  • 457
  • 625
  • The great thing about undefined behaviour is that the compiler can do anything it wants. Even things that are completely unrelated to the undefined behaviour, i's best avoided at all times. – Will Sep 27 '12 at 08:49
  • 11
    Only integer division by zero results in undefined behaviour. According to the result this must be floating point division. – Klas Lindbäck Sep 27 '12 at 08:54
  • @KlasLindbäck see edit. The question is about C++. – Luchian Grigore Sep 27 '12 at 08:59
  • Hi Thanks for the responses. I'm sorry it's not clear from my question; I am using VC++ but the code is C code, however the source file has the extension cpp so I think it may be invoking the c++ copiler – user13267 Sep 28 '12 at 01:37
  • @LuchianGrigore, So is Klas' answer above right? – Pacerier Sep 22 '13 at 17:33
11

Quoting the latest draft of the ISO C++ standard, section 5.6 ([expr.mul]):

If the second operand of / or % is zero the behavior is undefined.

This applies to both integer and floating-point division.

A particular C++ implementation may conform to the IEEE floating-point standard, which has more specific requirements for division by zero, which which case the behavior may be well defined for that implementation. That's probably why floating-point division by zero yields Infinity in your implementation. But the C++ standard doesn't require IEEE floating-point behavior.

Keith Thompson
  • 254,901
  • 44
  • 429
  • 631
0

you can use the following code sniplet in C. it throws the exception. it works on linux donno about windows though

#include <fenv.h>

#include <TRandom.h>
static void __attribute__ ((constructor)) trapfpe(void)
{
    /* Enable some exceptions. At startup all exceptions are masked. */
    feenableexcept(FE_INVALID|FE_DIVBYZERO|FE_OVERFLOW);
}
mkuse
  • 2,250
  • 4
  • 32
  • 61