From owner-sc22wg5 Thu Aug 9 17:08:34 2001 Received: from mailhub.dfrc.nasa.gov (mailhub.dfrc.nasa.gov [130.134.81.12]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id RAA83196 for ; Thu, 9 Aug 2001 17:08:32 +0200 (CEST) (envelope-from maine@altair.dfrc.nasa.gov) Received: from mail.dfrc.nasa.gov by mailhub.dfrc.nasa.gov with ESMTP for SC22WG5@dkuug.dk; Thu, 9 Aug 2001 08:06:13 -0700 Received: from altair.dfrc.nasa.gov ([130.134.129.8]) by mail.dfrc.nasa.gov (Post.Office MTA v3.5.3 release 223 ID# 0-71686U2500L200S0V35) with ESMTP id gov for ; Thu, 9 Aug 2001 08:08:00 -0700 Received: (from maine@localhost) by altair.dfrc.nasa.gov (8.11.0/8.11.0) id f79F7wm06061; Thu, 9 Aug 2001 08:07:58 -0700 From: Richard Maine MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <15218.42830.470468.105936@altair.dfrc.nasa.gov> Date: Thu, 9 Aug 2001 08:07:58 -0700 (PDT) To: SC22WG5@dkuug.dk Subject: (SC22WG5.2170) Named Scratch Files in Fortran 2000 - Rationale In-Reply-To: <200108091200.OAA82583@dkuug.dk> References: <200108091200.OAA82583@dkuug.dk> X-Mailer: VM 6.75 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Dan Nagle writes: > The design flaw found is that by using the status= with > a value of scratch, the programmer can't inform the processor > what to do regarding an existing file of the same name > (which would have been conveyed by old, new or replace). My proposed fix would be to just delete named scratch files. Of course, this may just illustrate my intransigence, as I didn't like the idea in the first place. In my opinion, the cited ratioanle isn't sufficient. Namely: > >* 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. A processor that can't manage to do this on it's own is pretty lame. I'd consider there to be at least an order of magnitude more likelihood that this feature would cause accidental overwriting from user error than that it would fix such a problem. If a processor can't get this right, the solution is just to fix the processor. That's worth a bug report to the vendor. Further, if the user makes a habit of putting valuable files in the same place as the processor typically puts scratch files by default, then I'd add another order of magnitude to my estimate of the likelihood that the user in question is going to mess it up. I thought that at least 75% of the point of scratch files was to free the user from having to deal with this problem, as it is a trivial problem for the compiler to handle. (The other 25% of the point is the automatic deletion.) > >* This feature would allow the programmer to specify a location for > >the scratch file which has enough space for the scratch file's contents. While a useful feature, this seems adequately treated by features outside of the language - often mechanisms such as setting an appropriate environment variable. Putting this in the program source code doesn't seem like the most appropriate place. If the place with adequate space for scratch files tends to be long-term stable on a given system, then that calls out for some kind of global system default setting. If it tends to vary from time to time, then it is likely to be different when the program is written and when it is run; yes the program could ask for user input on the matter, but then the user might as well send his input more directly to the system runtimes via something like an environment variable without the program source code needing to be an intermediary. Many existing implementations do something like this; I don't see it as an improvement to move the issue into the source code. If none of the above is suitable, there is always the option of just making the file named and deleting it on close, with something to handle the cases where an abort might leave the file undeleted. > >* 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. This sounds like an application for named files to me. The second paragraph just reinforces it. If you actually *WANT* the processor to leave the file around if the program aborts, then that's exactly what happens with a named file that you fail to close (because the program aborts before the close that specifies statis='delete'). I don't claim that any of these are new arguments. To the contrary, they were all raised before and were apparently not persuasive to a majority. I probably ended up acceding to the consensus myself, on the theory that although I didn't much like adding named scratch files, it wasn't a big enough deal to be worth further argument. But if the question is being raised again anyway, I'll just dig up these old points as arguments why I think deleting the feature is an easy and appropriate fix. -- Richard Maine | Good judgment comes from experience; maine@altair.dfrc.nasa.gov | experience comes from bad judgment. | -- Mark Twain