Mail Archives: djgpp-workers/2003/06/13/23:51:18
Take a look at the following test program (ttrap.c):
/* test code generation */
#include <stdio.h>
#include <stdlib.h> /* rand, strtoul */
int main(int argc, char **argv)
{
int a, b, c;
unsigned int i, n;
n = 10;
if (argc > 1) n = strtoul(argv[1], NULL, 10);
if (!n) n = 10;
for (i = 0; i < n; i++) {
a = rand(); b = rand();
printf("%3u %10x + %10x = ", i, a, b);
fflush(stdout);
c = a + b;
printf("%10x\n", c);
}
return 0;
} /* main */
compiled with "gcc -O0 -ftrapv ttrap.c
It traps integer overflow quite nicely, although I don't approve
of the code generation (what happened to INTO). However if you
follow the code via "objdump -dS a.exe | less" you will find that
addition is performed by a subroutine, that eventually calls abort
(all with some number of prepended _s). The call to abort has NO
following code.
This works fine if the purpose is to abort. But why can't the
user set up a signal handler to trap SIGABRT, handle it, and
return? If so the program will be left in total limbo.
The code generation is obviously a gcc problem, but the overflow
handling is a library problem, and thus peculiar to DJGPP. Of
course, if I had my druthers it would do something other than call
abort, it should raise a distinctive signal.
The same problem appears in other places after raising a signal,
and that is also a gcc problem. As far as I am concerned every
"raise(SOMESIG)" should be followed by code that works if SOMESIG
is handleable, or "exit(EXIT_FAILURE)" if it is not. gcc code
generation seems to prevent this, or even testing the return value
of raise.
If you agree with me, maybe somebody will forward this to the
appropriate gcc maintainer? The library problem may really be a
gcc problem.
--
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT worldnet DOT att DOT net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
- Raw text -