Prev: Compiler writer questions
Next: Intel Fortran compiler for Windows crashing
From: Greg Lindahl on 4 May 2008 23:41
In article <1igeuzv.sq8yt61wrjlyxN%wclodius(a)los-alamos.net>,
William Clodius <wclodius(a)los-alamos.net> wrote:

>> Indirectly through the BACKSPACE command, you mean? You can't backspace
>> efficiently on a disk without the postfix.

>You can, but it requires the run time library to retain a record of the
>prefixes,

Uh, no. That would work if you read through the file before you start
backspacing. But users can easily start at the end of the file, and
users who just want to read the last record would be up in arms if
your implementation had to read the entire file to backspace one
record.

-- greg



From: John Harper on 6 May 2008 23:15
In article <2MCdncC4epJ6l7zVnZ2dnUVZ_j-dnZ2d(a)comcast.com>,
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:
>
>Neither the POSITION='APPEND' for OPEN, nor BACKSPACE mention
>that it might not work. I just notice, though, in the POS=
>option to READ and WRITE for Fortran 2003, 9.5.1.10:
>
> "A processor may prohibit the use of POS= with particular files
> that do not have the properties necessary to support random
> positioning. A processor may also prohibit positioning a
> particular file to any position prior to its current file
> position if the file does not have the properties necessary
> to support such positioning."
>
>So it might be that BACKSPACE also doesn't work on such files.

Glen's quote is not in a Constraint, so you might hit trouble at
run time instead of being warned at compile time. After all, the unit
number or file name may not be available at compile time.

-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.harper(a)vuw.ac.nz phone (+64)(4)463 6780 fax (+64)(4)463 5045


From: Richard Maine on 6 May 2008 23:38
John Harper <harper(a)mcs.vuw.ac.nz> wrote:

> Glen's quote is not in a Constraint, so you might hit trouble at
> run time instead of being warned at compile time. After all, the unit
> number or file name may not be available at compile time.

Change "might" to some variant of "almost certainly." The odds of the
compiler figuring out that a backspace is on a unit that was connected
to a file with that property is negligable. If there is a problem, it
will almost certainly show up at run time rather than compile time.

In the standard, there is also the huge caveat that applies to all I/O.
I'll not bother looking up the exact words, but the rough translation is
"the processor can refuse to do darn near anything that it doesn't feel
like doing for any reason".

I was more referring to actual processors than to provisions of the
standard. Per the above, the standard allows just about anything in I/O
to be restricted, so it isn't particularly interesting to try to
elaborate everything that it alows. Glenn's quote does show that some
limitations on POS= were specifically anticipated as likely, which
matches well with my recollection. But that's not directly related to my
comment about open with append anyway. Open with append preceded POS= in
the language.

The disallowance of backspace after open with append was more of a
surprise to me... if I'm not confusing it with something else, which is
quite possible.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
First  |  Prev  | 
Pages: 1 2
Prev: Compiler writer questions
Next: Intel Fortran compiler for Windows crashing