1
int main()
{
    int x = 5, y = 0;
    int z = x / y;
    return 0;
}

I know that it comes under undefined behavior, but does it mean segmentation fault? And how does CPU handle divided by 0 case?

When I run this I get Floating point exception (core dumped).

user694733
  • 15,208
  • 2
  • 42
  • 68
Ayushi
  • 11
  • 4
  • 3
    A floating point exception is not a segmentation fault. – JJJ Jul 04 '18 at 10:23
  • If you are asking of effects on specific system, then please [edit] your question and tell us what system. – user694733 Jul 04 '18 at 10:40
  • The CPU handles it by tossing out a hardware exception. And that's it, it has nothing to do with the C language or the OS. – Lundin Jul 04 '18 at 10:41
  • 3
    pointless UB question, see the meaning of **undefined**. What exactly happens depends on your machine and environment. BTW, a division by 0 **can** be well-defined on floating-point types, if IEEE-754 format is used. –  Jul 04 '18 at 10:59

2 Answers2

7

If the behavior is undefined, it means there is no definition for what happens. So posing the question "does it mean segmentation fault" means you're missing the point. Anything can happen.

Also, there are many CPUs, and you don't specify one, so answering "how does CPU handle divide by 0" is of course also impossible.

You can catch exceptions, and handle them in code.

unwind
  • 391,730
  • 64
  • 469
  • 606
5

In general, a floating point exception is an example of the more general class of exceptions. The specifics will vary from machine to machine.

There are a number of things that can "kill" your program, and all of these can be classified as exceptions in this regard:

  • access to nonexistent memory
  • improper access to memory (misaligned, write to read-only, etc.)
  • divide by 0
  • illegal instruction
  • resource limit exceeded (e.g. CPU time)
  • arithmetic overflow

Under Unix-like operating systems, access to nonexistent memory is typically a "segmentation violation", while improper access to memory is typically a "bus error". (Under Windows they are/were a General Protection Violation, and/or a BSOD.)

And as you can see, although dividing by 0 is an exception, it's a sibling of a segmentation violation, not a subset.

(I've listed arithmetic overflow as an exception because it could be, not because it usually is. Most of today's systems do not treat overflow as an exception, of course. But by the rules of C they could, with the exception of overflows on unsigned integers, which are required by C to be defined and well-behaved.)

Under Unix-like operating systems, most/all of these exceptions tend to be mapped to signals, which your program can catch so that it can (attempt to) continue rather than dying.

(Ironically, on the system where I just tried it, integer divide-by-0 gives me a "floating point exception", while a floating-point divide-by-0 gives me an IEEE-754 inf, which is not an exception at all. But that's a different question.)

Steve Summit
  • 45,437
  • 7
  • 70
  • 103
  • It is UB: *"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.**"* – user694733 Jul 04 '18 at 10:42
  • @user694733 Thanks. (You've saved me a trip downstairs to fetch my copy of the Standard.) Sentence deleted. – Steve Summit Jul 04 '18 at 10:53
  • FYI [SIGFPE is a misnomer and is not limited to floating pointer errors but general erroneous arithmetic operations. Apparently goes back to PDP-11](https://twitter.com/shafikyaghmour/status/990937975595843584) – Shafik Yaghmour Jul 05 '18 at 05:55
  • Also note [that is the implementation support Annex F then floating point divide by zero is not undefined behavior](https://twitter.com/shafikyaghmour/status/1000222871434575873) – Shafik Yaghmour Jul 05 '18 at 06:02