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 


(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