4

When I compile the program:

#include <stdio.h>

int main(void)
{
    int x, y = 0;

    x = 1 / y;
    printf("x = %d\n", x);
    return 0;
}

It gives "Floating point exception (core dumped)"

However, when I compile:

#include <stdio.h>

int main(void)
{
    double x, y = 0;

    x = 1 / y;
    printf("x = %f\n", x);
    return 0;
}

It prints "x = inf"

Why does it return x as an infinite value if you're using double but returns an error if you're using int?

Weather Vane
  • 33,872
  • 7
  • 36
  • 56
Evan Waddicor
  • 101
  • 1
  • 4

3 Answers3

7

The C standard explicitly states that dividing by zero has undefined behavior for either integer or floating-point operands.

C11 6.5.5 paragraph 5:

The result of the / operator is the quotient from the division of the first operand by the second; the result of the % operator is the remainder. In both operations, if the value of the second operand is zero, the behavior is undefined.

Undefined behavior means that the standard says nothing about what happens. It could yield a meaningful or meaningless result, it could crash, or it could, as the standard joke goes, make demons fly out of your nose. (Of course the latter isn't going to happen, but it wouldn't violate the C standard if it did.)

Floating-point types, unlike integer types, often have special values that don't represent numbers. The IEEE floating-point standard specifies that division by zero can yield a result of Infinity, which is what your implementation is doing. There is no "Infinity" value for integers. (Note that C implementations may or may not conform to the IEEE floating-point standard.)

This question discusses the semantics of division by zero in IEEE floating-point.

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

C standard defines that the behaviour of a division by zero on operands of arithmetic types is undefined (cf., for example, this online C standard draft):

6.5.5 Multiplicative operators

2 Each of the operands shall have arithmetic type. The operands of the % operator shall have integer type.

5 The result of the / operator is the quotient from the division of the first operand by the second; the result of the % operator is the remainder. In both operations, if the value of the second operand is zero, the behavior is undefined.

And this rule explicitly includes floating point values, since the term arithmetic types means integral values and floating point values:

6.2.5 Types

18 Integer and floating types are collectively called arithmetic types.

Hence, both of your examples are actually undefined behaviour, and each compiler may specify on its own how to treat your statements. And thus it is standard-conform if a compiler treats the integral-division-by-zero as an exception, whereas the floating-point-division-by-zero gives the special value inf. Note: the standard does not define that this has to be the case.

Stephan Lechner
  • 34,891
  • 4
  • 35
  • 58
3

A floating point variable can actually store a value representing infinity. (It is the value INFINITY defined in math.h.) But there is no integer representation of infinity, so the only thing to do is fail.

Willis Blackburn
  • 8,068
  • 19
  • 36
  • 1
    It's not the only thing to do. There might happen endless things, like [demons may spawn out of your nose](https://en.wikipedia.org/wiki/Undefined_behavior). – KamilCuk Feb 01 '19 at 23:36
  • 1
    It's probably worth pointing out that infinity is not the mathematically correct result of dividing a number by zero -- rather, the result is mathematically undefined. – Jeremy Friesner Feb 01 '19 at 23:41
  • 1
    @JeremyFriesner: True, but the IEEE floating-point standard does specify Infinity as the result of division by zero (for some settings). A C implementation may or may not conform to IEEE. – Keith Thompson Feb 01 '19 at 23:43
  • @JeremyFriesner: Shouldn't 1.0/0.0 be NaN then? The infinity comes into play when you take a limit of 1.0/*x* as *x* tends to 0 from the left (- ∞) or the right (+ ∞). – jxh Feb 01 '19 at 23:44
  • @jxh: https://stackoverflow.com/q/14682005/827263 discusses the IEEE rules for division by zero. – Keith Thompson Feb 01 '19 at 23:46
  • Not in a newbie processor, which would take an inifinite amount of time computing it by subtraction. – Weather Vane Feb 01 '19 at 23:47
  • 2
    @JeremyFriesner: There is no one definition of arithmetic. Arithmetic arises out of axioms, and different systems of arithmetic suit different purposes, – Eric Postpischil Feb 01 '19 at 23:47
  • "so the only thing to do is fail."; actually not - the behaviour is undefined, and one cannot rely that "it fails" (whatever "fail" means). – Stephan Lechner Feb 02 '19 at 00:05
  • @StephanLechner actually IEEE is more applicable here than the C standard. – 0___________ Feb 02 '19 at 01:13
  • @P__J__: Engineering is not a process of guessing which specifications apply. They ought to be stated explicitly, and ideally correct design with desired behavior is logically derived from specifications. This question is tagged C and not IEEE-754, which tells us “This tag should be used with general questions concerning the C language, as defined in the ISO 9899 standard (the latest version, 9899:2018, unless otherwise specified—also tag version-specific requests with c89, c99, C11, etc).” So we are to prefer the C standard as a basis for answering. – Eric Postpischil Feb 02 '19 at 02:33
  • Okay, the result of dividing an integer by zero in C is technically undefined, but it's pretty obvious that on the OP's machine it produces an error. The OP asked why it was generating the error, not if he could rely on that behavior. – Willis Blackburn Feb 02 '19 at 02:54
  • @EricPostpischil disagreed. All marh hardware and library sofware follows the IEEE not the standard. Si – 0___________ Feb 02 '19 at 08:40
  • @P__J__: No, they do not. Even if they did, the question asks about C, not about hardware or libraries. – Eric Postpischil Feb 02 '19 at 12:26
  • @EricPostpischil this question is not possible to answer without taking into the account the implementation. Then it is UB which form the practical point of view does mean nothing when you do some numeric work – 0___________ Feb 02 '19 at 12:38
  • @P__J__: The notion that the unanswerability of a question justifies making assumptions is absurd. What would be reasonable is stating that C does not define the behavior but observing that the result obtained may be or even likely is because their implementation uses some features of IEEE 754, which is prevalent. Note that using some features of IEEE 754 is not the same as conforming to IEEE 754 and is not assuming that IEEE 754 applies. It is giving information to the OP which can lead them to further learning and investigation without asserting statements not known to be true. – Eric Postpischil Feb 02 '19 at 13:08