Date: Sat, 14 Jun 2003 11:38:06 +0300 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: djgpp-workers AT delorie DOT com Message-Id: <4098-Sat14Jun2003113806+0300-eliz@elta.co.il> X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9 In-reply-to: <3EEA9A4B.7B15E2A@yahoo.com> (message from CBFalconer on Fri, 13 Jun 2003 23:45:15 -0400) Subject: Re: Integer Overflow References: <3EEA9A4B DOT 7B15E2A AT yahoo DOT com> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > Date: Fri, 13 Jun 2003 23:45:15 -0400 > From: CBFalconer > > 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). Please show the code or disassembly fragment that you refer to here. I cannot quite understand what you don't like about the code. (It's also possible that I have a different compiler version installed, so please do tell what "gcc --version" prints on your machine.) > 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. As far as I could see, those functions where there's no code after the call to `abort' are from libgcc.a. They are part of the GCC distribution and are maintained by the GCC developers. So any problems with that code (and I agree that not having at least RET after the call to `abort' might be wrong) should be reported to the GCC forum. Having said that, I wonder what would be the Right Thing to do if the call to `abort' returns in this case. Also, if a program wants to be trapped on overflows, it should probably not have a SIGABRT handler that returns. That is, it's a documentation issue at most: tell in the GCC manual that programs compiled with -ftrapv had better not define such a handler. > The same problem appears in other places after raising a signal, > and that is also a gcc problem. What places are those? > The code generation is obviously a gcc problem, but the overflow > handling is a library problem, and thus peculiar to DJGPP. Please elaborate: how is overflow handling a library problem?