Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!cuuxb!mmengel
From: mmengel@cuuxb.ATT.COM (Marc W. Mengel)
Newsgroups: comp.lang.c
Subject: Re: some objections to 'noalias'
Message-ID: <1469@cuuxb.ATT.COM>
Date: 5 Jan 88 23:31:38 GMT
References: <485@cresswell.quintus.UUCP> <1453@cuuxb.ATT.COM> <492@cresswell.quintus.UUCP>
Reply-To: mmengel@cuuxb.UUCP (Marc W. Mengel)
Organization: AT&T-DSD, System Engineering for Resellers, Lisle IL
Lines: 115

In article <492@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>In article <1453@cuuxb.ATT.COM>, mmengel@cuuxb.ATT.COM (Marc W. Mengel)
[several corrections of my limited experience with FORTRAN]
	I was intending to give an example of aliasing
	caused by call-by-reference argument passing, and
	how it can lead to different results from essentially
	identical code.   All of the FORTRANs I have used use
	call by copy-in copy-out.  I never considered versions
	of f77 I have worked with ( the one from V7 unix, which 
	was kinda broken ) correct FORTRAN implementations, this
	should not neccesarily reflect on SUN's f77, which I have
	never used.

>I would claim that aliasing is a worse problem in Fortran than in
>C.  For example, the option of having cpxmpy accept records and
>return a record is not available in Fortran 77 (it IS available in
>Fortran 8X), so there simply isn't any safe way to write this in
>Fortran, while there is in C.

Aliasing is not a problem at all in the current C implementations.
There does not exist the call by reference/copy-in-copy-out
ambiguity, since all calls are by value, and explicit call
by reference can only be done using the address-of operator.
I never claimed that it was.  The problem is that the neccesity
of avoiding aliasing by always updating values at the end of
pointers (the way C currently behaves in all cases) is expensive,
and it would be useful to be able to tell the compiler that
it was "okay" to not do this updating in some cases.

>So my question: if people care about optimising Fortran (and they DO)
>and they care about writing correct programs in Fortran (and they DO)
>and if aliasing is a problem in Fortran (and I've just shown that it
>IS), what is so special about C that it needs a 'noalias' declaration?
>(By the way, there exist tools such as PFORT which can check that the
>Fortran no-aliasing rules are not violated.  But then Fortran is a
>much simpler language than C.)

Aliasing is not a problem in C. Ensuring that it is not a problem is
expensive.  People want to be able to turn off this expensive behavior
in specific cases where they know that it won't make a difference.

>The point that the C compiler already takes a great deal on blind
>faith is quite right, and it takes a lot of the steam out of my
>objections to 'noalias'.  But I think that explains the increasing
>popularity of C interpreters (one that sounded impressive was just
>announced on the net).  My experience has been that programs which
>use casts a lot are significantly harder to debug than ones which
>lint is happy with; has yours been any different?  Ok, so the boat
>is leaky; is that any reason to bore more holes in it?

lint is often perfectly happy with type casts; explicit casts are
often useful.  Programs that lint doesn't like are often buggy.
Your argument is really that we shouldn't give C programmers another
way to "shoot themselves in the foot."

[ discussion of how ANSI is nonetheless doing a far better job
than other standards orginizations]
>    --	'nolias' still does not mean "no alias" so the >name< is bad

I agree a better name would be nice, alas I haven't thought of one.
Have you?

>    --	it is still back-to-front
>    --	if "other languages do it" was a good enough argument for
>	giving parentheses more than merely grouping effect, then
>	"other languages do it" is a good enough argument for
>	having "noalias" be the default
	
	not regrouping parenthesis is legal in all current C definitions.

	assuming pointer references won't be aliased is not legal in
	any C spec I've seen.

	thats a big difference in my book.

>    --	pragma(noalias) is still a better approach
>	{what does #pragma do?  Surely a macro processor which may be
>	completely separate from the compiler is the wrong place for
>	such things?}

pragma(noalias) and pragma(const) and pragma(volatile) are functionally
equivalent to having keywords, the only difference is that in one case
we are creating more keywords (and we still have undefined ones like
"entry" lying around...).  We have a conflict between more keywords
or longer definitions.  A trade-off. ANSI chose keywords, I don't think
it makes a whole lot of difference either way.

>and Marc Mengel has not refuted these claims.

I still haven't refuted two of them, nor do I care to.  I do maintain
that 
	1) C currently assumes that pointers can point anywhere, and
	   therefore updates memory at the end of pointer references
	   before using other non-register variables on the assumption 
	   that the pointer may point to those variables.
	2) Changing this behavior in general will break many existing
	   programs which intentionally use aliasing.
	3) The optizations possible when the compiler knows
	   pointer references are not aliased are signifigant.

and that this means we need a noalias-type solution.  The people who
care whether it looks like:

	noalias int *pi;

versus

	pragma(noalias) int *pi;

can decide which they like better, it makes no difference to me whatsoever.
-- 
 Marc Mengel	

 attmail!mmengel
 ...!{moss|lll-crg|mtune|ihnp4}!cuuxb!mmengel