Why does the following code result in a floating-point exception?

/**
 * PROGRAM: div0.d
 *
 * Test integer division by zero
 */
import std.stdio;

void main(char[][] args)
{
    int a = 2;
    int b = 0;

    writefln("a/b = ", a/b);
}

$ bud div0.d $ ./div0 Floating point exception (core dumped)

"David Finlayson" <david.p.finlayson@gmail.com> wrote in message news:euom4m$2lmg$1@digitalmars.com...
> Why does the following code result in a floating-point exception?
>
> /**
> * PROGRAM: div0.d
> *
> * Test integer division by zero
> */
> import std.stdio;
>
> void main(char[][] args)
> {
>    int a = 2;
>    int b = 0;
>
>    writefln("a/b = ", a/b);
> }
>
> $ bud div0.d
> $ ./div0
> Floating point exception (core dumped)
>
>

Maybe it depends on the system?  On Windows I get the error "Integer Divide by Zero".

Jarrett Billingsley Wrote:


> Maybe it depends on the system?  On Windows I get the error "Integer Divide by Zero".
> 
> 

My system is:

Digital Mars D Compiler v1.009

running on

Linux 2.6.17-11-generic #2 SMP Thu Feb 1 19:52:28 UTC 2007 i686 GNU/Linux
(Ubuntu)

If that combo is up-to-date, then I will try and report a bug. I think the program is dumping core and not emitting a proper exception anyway.

David

David Finlayson wrote:
> If that combo is up-to-date, then I will try and report a bug. I think the program is dumping core and not emitting a proper exception anyway.

I cannot catch that exception either. Ubuntu 7.04, dmd 1.010.

Jari-Matti Mäkelä wrote:

> David Finlayson wrote:
>> If that combo is up-to-date, then I will try and report a bug. I think the program is dumping core and not emitting a proper exception anyway.
> 
> I cannot catch that exception either. Ubuntu 7.04, dmd 1.010.

It is probably not an D exception but a unix signal, if I remember corectlly unix gives a process the floating point exception signal on divide by 0.

Johan Granberg Wrote:

> It is probably not an D exception but a unix signal, if I remember corectlly unix gives a process the floating point exception signal on divide by 0.

So, is this a bug or a feature? If it is normal, it seems like this undermines the exception mechanism built into the language.

David Finlayson wrote:

>> It is probably not an D exception but a unix signal, if I remember corectlly
>> unix gives a process the floating point exception signal on divide by 0.
> 
> So, is this a bug or a feature? If it is normal, it seems like this
> undermines the exception mechanism built into the language.

The hardware exceptions are considered "part of" the D mechanisms too,
for instance dereferencing a null pointer will give you a similar error.


BTW; If I run your program (with the debugger) on Mac OS X, I get:

Program received signal EXC_ARITHMETIC, Arithmetic exception.
0x00002e21 in D main (args={length = 1, ptr = 0x300550}) at div0.d:13
13          writefln("a/b = ", a/b);

Interestingly, this only happens on X86. The PPC happily outputs:
a/b = 0

So I guess it is ultimately up to how the architecture handles it...
But for the Intel architecture you probably want to check for it ?

--anders

The x86 architecture will perform either a fault or a trap when the instruction DIV or MOD is used, and the second operand is a 0.  A fault or a trap, is when it ceases execution and instead executes:

function* IDT[0x??], which is the divide by zero handler for the system.  Each operating system has to write their own handler, and it's often just a "throw an error to the command line, durr".

Faults stop before the instruction, Traps stop after, or the other way around.  Can't remember.