This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH to implement `restrict' in C
- To: Joe Buck <jbuck at synopsys dot com>
- Subject: Re: PATCH to implement `restrict' in C
- From: "Lassi A. Tuura" <lat at iki dot fi>
- Date: Fri, 16 Oct 1998 19:09:28 +0200 (CET)
- cc: egcs at cygnus dot com
- Reply-To: "Lassi A. Tuura" <lat at iki dot fi>
|> > `__assume(expr)'
|> Ah, but they could have done this without asking people to change their
|> code: 'assert' would expand to __assume if NDEBUG is defined. It isn't
|> necessary to invent a new user-level construct.
Well, actually MS talks on the web about `ASSERT' macros not `assert'.
They show several variants: one that always asserts and another that
asserts only in debug builds. Presumably the new version of MFC (their
class library for Windows programming) will use these. Sorry for
creating the confusion about what MS really said.
As a motivation, I know some packages use something like PRE_CONDITION
or POST_CONDITION. I also define in a package of mine `ASSERT' that is
fancier than many compiler-generated variants: mine lets me ignore the
assertation (useful when the problem can be fixed with breakpoint
commands in a debugger), or drop a core, or dump a stack trace, or any
combination of these. It would be nice to be able to convert these into
something like `__assume' on compilers that can benefit from it.
Basically, as a developer I don't really care what the mechanism is to
tell compiler about these matters. It definitely seems to me to be nice
to be able to give compiler optimisation hints beyond using `assert' --
i.e. whatever `assert' uses internally is made available to developers
as a compiler extension.
My $0.02,
//lat
--
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going
to land, and it could be dangerous sitting under them as they fly
overhead. --RFC1925, "The Twelve Networking Truths"