This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Functions that always return
- To: Mike Stump <mrs at windriver dot com>
- Subject: Re: Functions that always return
- From: Michael Hayes <mhayes at redhat dot com>
- Date: Sun, 29 Oct 2000 13:56:46 +1300 (NZDT)
- Cc: gcc at gcc dot gnu dot org, mhayes at redhat dot com
- References: <200010281455.HAA05917@kankakee.wrs.com>
Mike Stump writes:
> You can never know if anything returns. Almost all functions are
> permitted to longjmp, call exit or loop infinitely, because of this,
> you can't know that they return.
I should have been more explicit; I was thinking in terms of libcalls
or functions explicitly marked pure or const. In particular,
the shadowing of a mem by a register across a libcall.
> As a group, we need to stop using the phrase expcetion to mean a
> signaling event and only use the word to mean things related to the
> file except.c. I'd propose raise a signal, fault or interrupt.
How about trap? I think this is the more common synonym for a
processor exception and is also used in the sources.
We should have some docs on this and for REG_EH_REGION (this is not
documented in rtl.texi).
Michael.