www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Integer division by zero results in floating-point exception !?

reply David Finlayson <david.p.finlayson gmail.com> writes:
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)
Apr 01 2007
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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".
Apr 01 2007
parent reply David Finlayson <david.p.finlayson gmail.com> writes:
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
Apr 01 2007
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
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.
Apr 02 2007
parent reply Johan Granberg <lijat.meREM OVEgmail.com> writes:
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.
Apr 02 2007
parent reply David Finlayson <david.p.finlayson gmail.com> writes:
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.
Apr 02 2007
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Apr 02 2007
parent Dan <murpsoft hotmail.com> writes:
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.
Apr 03 2007