From: "Wojciech Borkowski (afiliate)" <borkowsk AT bifur DOT SCI DOT FAU DOT EDU>
Message-Id: <9603011143.ZM13734@bifur.sci.fau.edu>
Date: Fri, 1 Mar 1996 11:43:57 -0800
To: djgpp AT delorie DOT com
Subject: signals on Windows 95 .
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="PART-BOUNDARY=.19603011143.ZM13734.sci.fau.edu"

--
--PART-BOUNDARY=.19603011143.ZM13734.sci.fau.edu
Content-Type: text/plain; charset=us-ascii


-- 
********************************************************************************
				Wojciech Borkowski 
		from Zaklad Systematyki i Geografii Roslin UW
		  temporary at Florida Atlantic University
********************************************************************************

--PART-BOUNDARY=.19603011143.ZM13734.sci.fau.edu
X-Zm-Content-Name: gcc_signal.cc
Content-Description: Text
Content-Type: text/plain ; name="gcc_signal.cc" ; charset=us-ascii ; x-irix-type=AsciiTextFile

 
	I have try to test DJGPP v 2.0 exception support on
DELL OptiPlex GXMT 5133 (Pentium 133) under Windows 95.
What hapened?
First time program worked correctly - printed :
"MAIN ENTERED"
"exception..!"

 But next time the FPU exception was hapened before the
program has entered into "main" routine.
Also any other DJGPP program runned just after the
test program had FPU exception on the begining.

It seems like the DJGPP runtime (go32_v2 ?) don't
clear FPU befor entry of signal handler. For unix
compatybility it should be done in the background.
 
Second way for fixing this is "manually" clear
the FPU in signal handler. In Borland C++ is function
 _clear87, which can do that. I don't know, is similar
function in DJGPP.


/*
 exceptions and signal test program  t.c
 for DJGPP v. 2 / DOS (gcc 2.7.2)
 compiled with defaults :
 gcc -o t t.c  -lm

*/
#include <stdio.h>
#include <signal.h>
#include <math.h>

void exception(int j)
{
fprintf(stderr,"exception..!") ;
exit(1);
}

double one=1, zero=0;

main()
{
double res;
fprintf(stderr,"MAIN ENTERED\n");

/* actually a combination of the following lines has worked on an
older '386 machine, but not on a particular '486 DX2 66 we have here,
causing an endless hanging of the prog not interruptible. Thus this
kind of prog should be tested on various PC's to see what happens. */

signal(SIGFPE, exception);

/* signal(SIGFPE, SIG_IGN);       */

/* raise(SIGFPE); */
res = one/zero;
res = log(zero);
return res=-1.0;
}


--PART-BOUNDARY=.19603011143.ZM13734.sci.fau.edu--