Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: explicit runtime condition code checking, particularly overflow
Message-ID: <6778@brl-smoke.ARPA>
Date: Wed, 2-Dec-87 13:58:43 EST
Article-I.D.: brl-smok.6778
Posted: Wed Dec  2 13:58:43 1987
Date-Received: Sat, 5-Dec-87 15:50:39 EST
References: <574@vax1.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) )
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 26
Keywords: runtime condition condition_code checking overflow

In article <574@vax1.UUCP> en2j@vax1.ccs.cornell.edu writes:
>In particular, I'd like to know if there's any way to write a line of
>C code which essentially translates into a Branch On Overflow, or Bcc LABEL, 
>where B means branch, cc is a condition code, and label is the name of a 
>procedure.

No, and the main reason is that C is at a higher level than that.
A single C expression may involve possible setting of the condition
codes several times during evaluation, and due to optimization you
can't normally even be sure what code will be generated; for example
it may depend on whether there are any free scratch registers
available, which in turn is affected by global aspects of the code.

If your hardware generates (or can be asked to generate) traps on
arithmetic exceptions, then there is a chance you can detect some
kinds of "overflow".  For example, a floating-point division by
zero often results in a SIGFPE being sent to your process, and you
can set up a signal handler in advance to field SIGFPE and take
some appropriate action (normally a longjmp()).  However, beware
that the C implementation may be assuming certain things about the
runtime environment, notably that integer overflow does not cause
a trap, and changing such aspects of your environment can break
the code that the compiler generates.  (Someone actually did that
once here -- he turned on floating-point overflow trapping on our
Gould PowerNodes, not realizing that due to a silly design defect
that it also enabled integer arithmetic exception traps.)