Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!uwm.edu!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!ames!skipper!elxsi!maine From: maine@elxsi.dfrf.nasa.gov (Richard Maine) Newsgroups: comp.lang.fortran Subject: Re: write array Message-ID: Date: 3 Jul 90 15:05:52 GMT References: <112121@linus.mitre.org> Sender: news@skipper.dfrf.nasa.gov Distribution: usa Organization: NASA Dryden, Edwards, Cal. Lines: 52 In-reply-to: khb@chiba.Eng.Sun.COM's message of 29 Jun 90 22:19:57 GMT 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]