Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!netnews.upenn.edu!msuinfo!news From: fox@VIXEN.NSCL.MSU.EDU Newsgroups: comp.lang.fortran Subject: Re: write array Message-ID: <1990Jul5.121842.29471@msuinfo.cl.msu.edu> Date: 5 Jul 90 12:17:14 GMT Sender: news@msuinfo.cl.msu.edu Distribution: usa Organization: National Superconducting Cyclotron Lab Lines: 46 In article , 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