Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ucsfcgl!seibel
From: seibel@cgl.ucsf.edu (George Seibel)
Newsgroups: comp.lang.fortran
Subject: Re: CHARACTER EQUIVALENCE (Was Re: fortran to C converter)
Message-ID: <11538@cgl.ucsf.EDU>
Date: 22 Apr 89 01:51:02 GMT
References: <67044@pyramid.pyramid.com> <1390@hudson.acc.virginia.edu>
Sender: daemon@cgl.ucsf.edu
Reply-To: seibel@hegel.mmwb.ucsf.edu.UUCP (George Seibel)
Organization: Computer Graphics Lab, UCSF
Lines: 22

In article <1390@hudson.acc.virginia.edu> gsh7w@astsun1.acc.Virginia.EDU (Greg Hennessy) writes:

]#In article <50500123@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:
]#>   In some sicko implementations, and in pure ANSI F77 itself, you
]#>have to have a separate common block for characters (UGH!).

]In article <67044@pyramid.pyramid.com>  (Mike Lipsie) writes:
]#If you allow equivalence
]#between CHARACTER and non-CHARACTER variables, you automatically have
]#non-portable code.

]Is it just me or does this answer pertain to a different question? I
]don't see what EQUIVALENCE has to do with seperate common blocks.

Yeah - although it's true that EQUIV's between char and other types
is non portable.   The point of not mixing character and other types
in common has to do with data alignment, since character data might
not fall on word boundaries.   Beats me why it couldn't be padded out
to the nearest word, though.  That's probably what most implementations
do;  I've never seen a compiler that enforced the no-mixing rule.

George Seibel, UCSF