From owner-sc22wg5 Wed Aug 8 20:50:03 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id UAA79053 for ; Wed, 8 Aug 2001 20:49:59 +0200 (CEST) (envelope-from keith.bierman@sun.com) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14849; Wed, 8 Aug 2001 12:49:52 -0600 (MDT) Received: from holosuite.Eng.Sun.COM (holosuite.Eng.Sun.COM [152.70.61.44]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10462; Wed, 8 Aug 2001 11:49:54 -0700 (PDT) Received: from sun.com (computer [152.70.61.50]) by holosuite.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id LAA20000; Wed, 8 Aug 2001 11:49:53 -0700 (PDT) Sender: khb@holosuite.Eng.Sun.COM Message-ID: <3B7189D1.2E1604E9@sun.com> Date: Wed, 08 Aug 2001 11:49:53 -0700 From: keith bierman Reply-To: Keith.Bierman@sun.com Organization: SunMicrosystems Laboratories X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en,pdf MIME-Version: 1.0 To: John Reid CC: SC22WG5@dkuug.dk Subject: Re: (SC22WG5.2165) Named Scratch Files in Fortran 2000 - Rationale References: <200108080821.KAA77047@dkuug.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Reid wrote: > > - > Here is a copy of the Rationale from both papers. > [Begin Rationale] > Rationale > Currently, the Fortran standard does not allow the user to name > scratch files. Not allowing the user to name scratch files is an > unnecessary irregularity. A named scratch file would be the only kind > of named file which would be automatically deleted when the file is > closed or execution terminates. > > Allowing Fortran programmers to give names to scratch files would > have several advantages. These advantages include: 1) > * This feature would allow the programmer to protect against > accidentally overwriting existing files. This could happen if the > processor generates a file name which is the same as the name of an > existing file. 2) > * This feature would allow the programmer to specify a location for > the scratch file which has enough space for the scratch file's contents. > 3) > * The programmer could look at a scratch file's contents during > execution. > > If the processor does not delete scratch files if the program > crashes, this feature would allow the programmer to do some post-mortem > analysis. > [End of Rationale] > For whatever it is worth, I would note that (1) doesn't seem very compelling (why can't the processor be expected to always generate a unique name?). (2) however, can be quite useful. In my experience more for performance than for the size (viz. being able to control if scratch files are memory resident (virtual files), real files on local storage, or real storage on the network .... Personally, I have found such facilities to be useful in the past.