Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!uunet!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!roundup.crhc.uiuc.edu!ux1.cso.uiuc.edu!hirchert
From: hirchert@ncsa.uiuc.edu (Kurt Hirchert)
Newsgroups: comp.lang.fortran
Subject: Re: I/O
Message-ID: <1991Jan30.184823.22588@ncsa.uiuc.edu>
Date: 30 Jan 91 18:48:23 GMT
References: <27a6aacc@ThreeL.co.uk> <1991Jan30.150622.16144@ux1.cso.uiuc.edu>
Sender: news@ux1.cso.uiuc.edu (News)
Organization: NCSA - National Center for Supercomputing Applications
Lines: 63
Originator: hirchert@harriett

In article <1991Jan30.150622.16144@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes:
>
>In article <27a6aacc@ThreeL.co.uk> jf@threel.co.uk (John Fisher) writes:
>>mkh6317@rigel.tamu.edu (HOWARD, MATTHEW KENDALL) asks:
>>
>>> 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.
>>
>>Why the sneer quotes round standard?
>>
>>Reason: because it's very unportable.  Why?
>>
>>1) Endian problems
>
>That is not the reasson. You CAN equivalence real and double precision,
>which has the same problem - or, for that matter, integer and logical!!
>
>
>>3) Character-code problems
>
>Not a problem either. So long as you don't try to read a character as
>an integer or vice-versa, which is not conforming anyway.

As Doug points out, neither of these would really be problems, since the
standard already prohibits retrieving data using a type different than the
type through which it was stored (except in the special case of real vs.
complex).  Of course, that very prohibition undermines the reason most
people seem to want to EQUIVALENCE character and non-character data.
>
>>2) Word-length problems
>
>This is the apparent hang-up. Actually, it really isn't a problem, but
>IS why Sigmund Freud invented the term "anal retentive personality".

It's more of a problem than Doug thinks.  There are even machines out there
where the number of characters/word is not an integer value.  Where the problem
gets serious is when alignment issues get involved.  For example

      real a,b
      character c(80)
      equivalence (a,c(1)),(b,c(5))

If equivalence between character and non-character data is allowed, should the
above be legal or not?  On a machine with 4 characters/word, it's no problem,
but on a machine with 5, 7.5, 8 or 10 characters/word, this can cause severe
alignment problems.

Now if the committee had been willing to significantly complicate the
description of storage association, I believe it would have been possible to
resolve these issues, but what would have been the point?  The only portable
thing that could have been done with this "feature" would have been to reduce
storage usage by putting a character array and non-character array used at
different times in the same place.  Given the rarity of people using
EQUIVALENCE to reduce memory usage, this simply didn't seem worth the effort.

Note that a standard-conforming compiler _can_ allow EQUIVALENCE between
character and non-character data, it's just that a standard-conforming
program (i.e., a portable program) can't make use of such a feature.
-- 
Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
National Center for Supercomputing Applications