Path: utzoo!attcan!uunet!samsung!umich!sharkey!bnlux0!bam
From: bam@bnlux0.bnl.gov (Bruce A. Martin)
Newsgroups: comp.lang.misc
Subject: Re: C vs. FORTRAN (was C official DOD langauge?)
Message-ID: <1915@bnlux0.bnl.gov>
Date: 7 Jun 90 15:22:56 GMT
References: <1633@dinl.mmc.UUCP> <3169@goanna.cs.rmit.oz.au>
Organization: Grumman Aircraft Systems (& X3J3)
Lines: 42

In article <3169@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>In article <1633@dinl.mmc.UUCP>, noren@dinl.uucp (Charles Noren) writes:
> 

... 	[Much interesting dialog.]
...	[My quibble is only with the following:  ]


>:           (Question:  It's been so long since I've used
>:           FORTRAN, but how does the EQUIVELANCE statement
>:           affect or not affect aliasing?)
>
>If you're using one of the variables in an EQUIVALENCE group,
>what you get when you use one of the others isn't defined.


Welll....   Not quite!
What I think you meant to say is:

	If you're using one of the variables in an EQUIVALENCE group,
	what you get when you use one of the others that has a
	DIFFERENT TYPE is undefined.

Of course, all variables (aliases, actually) in the EQUIVALENCE group
which have the SAME TYPE do become defined and have the same value after
one of them has been defined (provided none of the others of differing
type has become defined more recently).

{Gee!  It's is a lot harder to say than to understand.  
Anyhow, this use of EQUIVALENCE is really no different from "union".}


	    -/s/-					BAM
	Bruce A. Martin	
	Grumman Aircraft Systems 	[Address given for identification only.]
	(Mailstop C02-106)		[Every conceivable disclaimer applies!!]
	Bethpage, NY  11714-3582	[Opinions are mine only, & will change,]
	 (516) 577-1085			[without notice, whenever appropriate!!]


P.S.  Sorry.  I do not know what the "EQUIVELENCE" statement does!   $8-D
(Refer to "alt.flame.spelling" for further information.)