cazier@mbunix.mitre.org (Cazier) (06/30/90)
I bumped into some code a few months ago that works on some compilers
but not all, yet the author claims the code to be completely portable.
As I rewrote the code to what I find to be 100% portable, I'm now curious
about the sample code shown below:
write (...) KA
where KA is really KA(j) where "j" goes from 1-n.
As I rewrote it, I simply used an implied do-loop and found the code
to work on those systems where where the original code would not, i.e.
write(...) (KA(j), j=1,n)
Am I missing something about why the write (...) KA is supposed to be
portable? Is something wrong "standards"-wise with those compilers
which do not support such a construct?maine@elxsi.dfrf.nasa.gov (Richard Maine) (07/03/90)
On 29 Jun 90 22:19:57 GMT, khb@chiba.Eng.Sun.COM (Keith Bierman - SPD Advanced Languages) said:
Keith> Page 12-12 of x3.9-1978 (aka fortran 77 standard)
Keith> If an array name appears as an i/o list item, it is treated as if all
Keith> the elements of the array were specified in the order given by array
Keith> element ordering (5.2.4). The name of an assumed-size dummy array must
Keith> not appear as an input/output list item.
Keith> Compilers which don't accept this are not comformant with the
Keith> standard.
Yes, but do note the restriction. The code fragment
real a(10)
...
call sub(a)
...
subroutine sub(a)
real a(*)
...
write (unit) a
...
is not legal and will not work on most compilers. I have seen several
people try this erroneous construct, thinking that the array size would
be passed from the calling routine.
I'd guess that the code referred to in the original posting did not have
this particular problem though because it was claimed to work on at least
some systems. Thus, I think Keith is correct in implying that the original
poster has found a "broken" compiler. I'm almost sure that even FORTRAN 66
allowed the whole array notation, though my memory of those days is getting
a little rusty and it doesn't seem worth looking up at the moment.
Another comment. (Ignoring the case where A is an assumed size dummy array),
some compilers will produce substantially more efficient code for
write (unit) a
than for
write (unit) (a(i),i=1,n)
The later syntax may generate a loop with n calls to the system i/o routines
(and thus n executations of some of the overhead), whereas the former
usually generates a single call for the vector of n values. Many (most?)
compilers recognize the implied DO above as a special case that can be
optimized to the same code as the first syntax, but I have run into some
compilers that did no such optimization.
--
Richard Maine
maine@elxsi.dfrf.nasa.gov [130.134.64.6]fox@VIXEN.NSCL.MSU.EDU (07/05/90)
In article <MAINE.90Jul3080552@altair.dfrf.nasa.gov>, maine@elxsi.dfrf.nasa.gov (Richard Maine) writes... >On 29 Jun 90 22:19:57 GMT, khb@chiba.Eng.Sun.COM (Keith Bierman - SPD Advanced Languages) said: > >Keith> Page 12-12 of x3.9-1978 (aka fortran 77 standard) > >Keith> If an array name appears as an i/o list item, it is treated as if all >Keith> the elements of the array were specified in the order given by array >Keith> element ordering (5.2.4). The name of an assumed-size dummy array must >Keith> not appear as an input/output list item. > >Keith> Compilers which don't accept this are not comformant with the >Keith> standard. > >Yes, but do note the restriction. The code fragment > > real a(10) > ... > call sub(a) > ... > subroutine sub(a) > real a(*) > ... > write (unit) a > ... > >is not legal and will not work on most compilers. I have seen several >people try this erroneous construct, thinking that the array size would >be passed from the calling routine. > >I'd guess that the code referred to in the original posting did not have >this particular problem though because it was claimed to work on at least >some systems. Not necessarily in the last sentence because there are *some* compilers which *do* pass array bounds information into subroutines. I these cases, I can conceive of a run time library/compiler combination for which the dummy array implied implied do (as this is known) will work. Ron Fox | FOX@MSUNSCL.BITNET | Where the name NSCL | FOX@CYCVAX.NSCL.MSU.EDU | goes on before Michigan State University | MSUHEP::CYCVAX::FOX | the quality East Lansing, MI 48824-1321 | | goes in. USA
smryan@garth.UUCP (sous-realiste) (07/14/90)
Assuming KA is declared by something like
. . .
DIMENSION KA(1:n)
. . .
> write (...) KA
Then the write is equivalent to
WRITE(...) (KA(j)=1,n)
or your compiler is broken.
[ DIMENSION KA(a:b,c:d,...)
WRITE(...) KA
should be the same as
WRITE(...) (...((KA(i,j,...),i=a,b),j=c,d)...)
]
--
Her somber eyes consider all ||/+\==/+\|| Steven Ryan
that loom and tower, large and tall.||\=/++\=/|| ...!uunet!ingr!apd!smryan
Her everyday is always new ||/=\++/=\||...!{apple|pyramid}!garth!smryan
and fills her eyes of frail blue. ||\+/==\+/|| 2400 Geng Road, Palo Alto, CA