Path: utzoo!utgpu!water!watmath!clyde!rutgers!ll-xn!husc6!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: some objections to 'noalias'
Summary: falsehood about Fortran
Message-ID: <492@cresswell.quintus.UUCP>
Date: 23 Dec 87 08:18:07 GMT
References: <485@cresswell.quintus.UUCP> <1453@cuuxb.ATT.COM>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 77

In article <1453@cuuxb.ATT.COM>, mmengel@cuuxb.ATT.COM (Marc W. Mengel)
writes several times that
> Fortran uses copy-in copy-out address passing
and says onces that
> (in current implementations) doesn't have an address-of operator.
Several current implementations DO have an address-of operator, not
that it matters.
The statement that Fortran uses pass-by-value-return (anyone remember
Algol W?) is simply false.  >>Some Fortran implementations<< use
valret.  They are allowed to.  Some Fortran implementations use
pass-by-reference.  They are allowed to.  Two Fortran compilers I have
used pick different methods for different functions, depending on
optimisation level.  They are allowed to.  If someone writes a Fortran
subroutine
	SUBROUTINE CPXMPY(RA,IA, RB,IB, RC, IC)
	    REAL RA,IA, RB,IB, RC,IC
	    RC = RA*RB - IA*IB
	    IC = RA*IB + RB*IA
	    RETURN
	END
then he is in precisely the same sort of trouble as the C programmer
who writes the C function you exhibited.  If you
	    CALL CPXMPY(RA,IA, RB,IB, RA,IA)
then you are going to have trouble in some Fortran implementations, and
it is YOUR fault, not theirs.
In fact, just now I tried this with the f77 compiler on a SUN-3/50
running SunOS 3.2.  With optimisation off, it gives the "incorrect"
answers, due to using pass-by-reference.  But with optimisation on
(f77 -O foo.f), it gives the "correct" answers, because it is making
local copies.  BOTH behaviours are in conformance with the standard;
it is the >program< which is non-conforming, not the compiler.

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.

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.)

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?

I should make it plain that my objection to 'noalias' was more vehement
than perhaps was warranted, because on the whole I am tremendously
impressed by the work of the ANSI C committee.  I am also watching the
British Standards Institute working group on Prolog; that is being done
in a most unprofessional fashion.  I have repeatedly begged them (given
that their mandate was to create a standard based on Edinburgh Prolog)
to do exactly that, and after some years they finally explicitly
rejected the idea.  They are busily inventing their own language.  After
watching that outfit bumble around, the ANSI C committee look amazingly
good.

    --	'nolias' still does not mean "no alias" so the >name< is bad
    --	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
    --	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?}
and Marc Mengel has not refuted these claims.