Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!apple!netcom!amdcad!sun!exodus!boise.Eng.Sun.COM!wsb
From: wsb@boise.Eng.Sun.COM (Walt Brainerd)
Newsgroups: comp.lang.fortran
Subject: Re: I/O
Summary: Why
Message-ID: <6632@exodus.Eng.Sun.COM>
Date: 25 Jan 91 17:23:49 GMT
References: <11498@helios.TAMU.EDU>
Sender: news@exodus.Eng.Sun.COM
Lines: 37

In article <11498@helios.TAMU.EDU>, mkh6317@rigel.tamu.edu (HOWARD, MATTHEW KENDALL) writes:
> 
> Ok, ok. Uncle.  Since I don't have a copy of the "standard" I
> will have to take your word that "equivalencing a character
> variable to a non-character variable" is a violation of the
> standard.    Now tell me why.
> 
The standard says nothing about how many bits any particular data
type must occupy, thought it does say that a real and integer
must occupy the _same_ amount of storage.  This is essential
to determine the effects of equivalence, common, argument
passing (ways that stuff gets associated).  Since there is no
connection between the amount of storage occupied by a character
and that occupied by an integer (for example), if equivalencing
them were allowed, the effects could not be described, so would
be processor dependent.  This sort of thing should be avoided
whenever possible in a standard whose primary purpose is to
provide portability.

Even if it were legal to equivalence the two data types,
assigning a value to one and using the value of the other
(as was done in the program under discussion)
is NOT LEGAL.  For example the following is illegal:

           EQUIVALENCE (I, R)
           I = 7
           PRINT *, R

Since all of this is nonstandard, your compiler may do what
it likes with it (extensions are explicitly permitted by
the standard) and to determine whether it might make sense,
the manual for your system must be consulted.
--
Walt Brainerd        Sun Microsystems, Inc.
wsb@eng.sun.com      MS MTV 5-40
                     Mountain View, CA 94043
                     415/336-5991