mkh6317@rigel.tamu.edu (HOWARD, MATTHEW KENDALL) (01/25/91)
All; 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. As Calivn Vu has shown, the problem is not related to the method used to initialize the variable. In this instance the data were interpreted rather than transfered. Double apologies to Pierre and Bill Matt
wsb@boise.Eng.Sun.COM (Walt Brainerd) (01/26/91)
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
buckland@cheddar.ucs.ubc.ca (Tony Buckland) (01/26/91)
In article <11498@helios.TAMU.EDU> mkh6317@rigel.tamu.edu 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. I assume you mean ``why was the standard made that way?" Depending on your point of view: (1) to make life miserable for everybody who had clever ways of manipulating character data in, or as though it were, variables of other types; (2) to achieve portability between systems which represent either character data or other types of data in different ways. What you are *not* supposed to do, for instance, is equivalence a four-character array to a fullword integer variable, set it to zero, and then detect digits in your input by feeding one character at a time into the right-hand byte and seeing if the integer is over 239 (if that seems incomprehensible, it's because the example is based on IBM 370 machines using EBCDIC coding, and proves the wisdom of (2)).
jf@threel.co.uk (John Fisher) (01/30/91)
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 2) Word-length problems 3) Character-code problems --John
mcdonald@aries.scs.uiuc.edu (Doug McDonald) (01/30/91)
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. >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". Doug McDonald
hirchert@ncsa.uiuc.edu (Kurt Hirchert) (01/31/91)
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
wws@raphael.cray.com (Walter Spector) (01/31/91)
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 > 2) Word-length problems > 3) Character-code problems All three very good reasons from a portablility point of view. Much of the use of this 'feature' is to avoid rewriting old Fortran-66 '8HHOLLERIT,1HH' based programs when adding new code. The new code uses character data type (for obvious maintainability reasons), but can still get at the old existing data structures. Porting large (.gt. 10**5 lines) Hollerith-based codes can be a nightmare. A fourth reason is word *alignment* problems. Not all the world is a VAX. (Actually, *none* of it was when the '77 standard was created.) Consider something approximating the following: character*100 string integer i equivalence (string(2:2),i) This would, if legal, force the integer to be equivalenced to the second character of the character variable. Since the integer would no longer be word-aligned, performance penalties would result on word-addressable machines. (I understand this is even true for most byte-addressable machines, since the hardware still doubles your memory references and then shifts to align - even if invisible to the programmer.) The same situation exists when mixing character and non-character data in common blocks. The '77 standard does not allow mixing in common either. Many compilers do support mixing of character/non-character types in equivalence/common. Some implementations only allow it when alignment rules are followed to avoid the performance problems. Consider: character*100 string integer i equivalence (string(1:1),i) The integer is word-aligned, and equivalencing is possible with no performance problems. Walt Spector (wws@renaissance.cray.com) Sunnyvale, California _._ _._ _.... _. ._.