Date:	Sat, 14 Jun 2003 11:38:06 +0300
From:	"Eli Zaretskii" <eliz AT elta DOT co DOT il>
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

> Date: Fri, 13 Jun 2003 23:45:15 -0400
> From: CBFalconer <cbfalconer AT yahoo DOT com>
> 
> 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?

- Raw text -