Path: utzoo!mnetor!uunet!husc6!think!ames!ucbcad!ucbvax!decvax!tektronix!midas!copper!timc
From: timc@copper.TEK.COM (Tim Carver)
Newsgroups: comp.lang.c
Subject: Re: (So-Called) ANSI C
Message-ID: <1574@copper.TEK.COM>
Date: 22 Dec 87 20:28:53 GMT
References: <4668@pyr.gatech.EDU> <3873@uw-june.UUCP> <6896@brl-smoke.ARPA>
Reply-To: timc@copper.UUCP (Tim Carver)
Organization: Tektronix, Inc., Beaverton, OR.
Lines: 41
Summary: I don't think so


In article <6896@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
> In article <3873@uw-june.UUCP> pardo@uw-june.UUCP (David Keppel) writes:
> >This is why I think pragmas are a better mechanism for doing things like
> >``noalias'', etc.  I'm now a little bothered that the debate over whether
> >to have ``noalias'' rages on yet nobody has talked about leaving the
> >language alone and using pragmas to get the optimizations...
> 
> There are (at least) two reasons for this.
> 	(1) X3J11 proposed "noalias".  They did not propose a specific
> 	pragma for this.
> 	(2) A #pragma cannot, according to the rules, alter program
> 	semantics.  Therefore it cannot be used to obtain the kind of
> 	optimization that "noalias" permits, because that IS
> 	semantically visible.

Would you tell us, please, what rules you are talking about ?  I haven't
seen anything in the standard that says pragmas "can't alter program
semantics".  They cause implementation-defined behaviour, period.

I agree with Mr. Keppel.  It seems to me that for the short term, #pragmas
would be an excellent way to get programmer hints to compilers.  X3J11 has
rejected lots of good ideas because of "lack of prior art, effect can be
achieved with existing features."   noalias should have been rejected for
this reason alone.  It isn't that noalias is such a bad idea;  it just isn't
a truly good one, and it is way too late to be adding features which are not
truly good ideas to the standard.  There are lots of other cute little hints
that we could use in different situations to improve code quality.  That does
not mean that it is appropriate to put them into the language specification.

I suspect that people who really have implemented highly optimizing C compilers
are going to be the people least likely to support noalias - it sounds too much
like somebody else's pet idea.

As to point (1), I don't think X3J11 should propose any specific pragma.
Those who want to do optimizing compilers which need added help from the
programmer can come up with their own pragma definitions for now.

A future standard could incorporate those ideas which prove really useful.

                                                        Tim Carver