please try this program

[robert....@oracle.com]

I am interested in knowing what the following program prints using
various compilers. Please try it and let me know which compiler you
are using and what the result is. Oracle Solaris Studio Fortran
produces output that is not standard conforming.

PROGRAM MAIN
CHARACTER*12 STR
OPEN (10, FILE='XXX', POSITION='REWIND')
WRITE (10, '(A)') 'ABCDEFGHIJKL'
REWIND 10
READ (10, '(TR4)', ADVANCE='NO')
WRITE (10, '(TL2, A)', ADVANCE='NO') 'MNOP'
REWIND 10
READ (10, '(A)') STR
PRINT '(A)', STR
END

[baf]

gfortran 4.7 (32-bit MinGW)

ABCDMNOP



gfortran 4.4.1 x86_64 suse-linux

ABCDMNOP

[Clive Page]

On 25/02/2012 06:38, robert....@oracle.com wrote:
> I am interested in knowing what the following program prints using
> various compilers.

Using g95 v0.92 Jun 17 2009 on Windows:

ABCDEFGHIJKL

Using nagfor release 5.2(721) on Linux:

ABCDMNOP


I'd be interested to know what you think standard behavior should produce.


--
Clive Page

[Edmund Dunlop]

Silverfrost FTN95/Win32 Ver. 6.10.0
- ABCDEFGHIJKL

Lahey/Fujitsu Fortran 95 Compiler Release 5.70f
- BCDMNOP
or ABCDMNOP if the penultimate statement is
changed to PRINT '(1X,A)', STR


<robert....@oracle.com> wrote in message
news:692388e2-b50b-436a...@s13g2000yqe.googlegroups.com...

--- Posted via news://freenews.netfront.net/ - Complaints to ne...@netfront.net ---

[robert....@oracle.com]

On Feb 25, 1:53 am, Clive Page <use...@page2.eu> wrote:

> On 25/02/2012 06:38, robert.corb...@oracle.com wrote:
>
> > I am interested in knowing what the following program prints using
> > various compilers.
>
> Using g95 v0.92 Jun 17 2009 on Windows:
>
> ABCDEFGHIJKL
>
> Using nagfor release 5.2(721) on Linux:
>
> ABCDMNOP
>
> I'd be interested to know what you think standard behavior should produce.

According to interpretation 000024 of the Fortran 95 standard

Page 136. At the end of the last paragraph of subclause 9.2.1.3.1
[136:33] add
If a nonadvancing output statement leaves a file positioned within
the current record and no further output statement is executed
for the file before it is closed or a BACKSPACE, ENDFILE, or REWIND
statement is executed for it, the file is positioned after the
current record before the specified action is performed.

The corresponding statement in the Fortran 2008 standard is
paragraph 2 of Clause 9.3.4.2. Based on that statement and
on paragraph 4 of non-normative Clause C.6.2 of the
Fortran 2008 standard, my reading is that the output should
be

ABCDMNOPIJKL

Bob Corbett

[Clive Page]

On 25/02/2012 10:33, robert....@oracle.com wrote:

> paragraph 2 of Clause 9.3.4.2. Based on that statement and
> on paragraph 4 of non-normative Clause C.6.2 of the
> Fortran 2008 standard, my reading is that the output should
> be
>
> ABCDMNOPIJKL

In that case, the search is still on for a compiler which does this
correctly.

Meanwhile on several machines I now have files called "XXX", which looks
very suspicious :-)


--
Clive Page

[robert....@oracle.com]

On Feb 25, 3:08 am, Clive Page <use...@page2.eu> wrote:

> Meanwhile on several machines I now have files called "XXX", which looks
> very suspicious :-)
>
> --
> Clive Page

Oh dear. I use the name "XXX" to indicate that the file is
inconsequential. Please feel free to change the name.

Bob Corbett

[Tim Prince]

Intel(R) Visual Fortran Intel(R) 64 , Version 12.1.3.300:
ABCDEFGHIJKL

x86_64-w64-mingw32/4.5.3/:
ABCDMNOP

--
Tim Prince

[Sebastian Hanigk]

robert....@oracle.com writes:

> I am interested in knowing what the following program prints using
> various compilers. Please try it and let me know which compiler you
> are using and what the result is. Oracle Solaris Studio Fortran
> produces output that is not standard conforming.

OSX 10.6.8 Intel

Intel(R) Fortran Intel(R) 64 Compiler Professional for applications running on Intel(R) 64, Version 11.1 Build 20090827 Package ID: m_cprof_p_11.1.067

ABCDEFGHIJKL


Solaris 10 10/09 s10x_u8wos_08a X86

Sun Fortran 95 8.4 SunOS_i386 Patch 141852-06 2010/06/30

MNOP

[Dick Hendrickson]

On 2/25/12 4:33 AM, robert....@oracle.com wrote:
> On Feb 25, 1:53 am, Clive Page<use...@page2.eu> wrote:
>> On 25/02/2012 06:38, robert.corb...@oracle.com wrote:
>>

Related to the problem of having several files named XXX on your
(Clive?) machine, I was told that the reason X3J3 was renamed J3 was
that many "smart" search engines would point people to X3J3 when they
searched for XXX. At least, that's what they told me.

Dick Hendrickson

[Rafik Zurob]

Hi

Output with IBM XL Fortran:

> ./a.out
MNOP
>

I'll look more closely into what the standard says on Monday.

Regards

Rafik

<robert....@oracle.com> wrote in message
news:692388e2-b50b-436a...@s13g2000yqe.googlegroups.com...

[Clive Page]

It was just my little joke.

But there is a serious point, namely that it's a pity that it isn't
easier to delete a file from Fortran, otherwise I've no doubt you would
have done that in your example.

Regards

--
Clive Page

[mecej4]

Pathscale 4.0.12.1, Linux X64 ABCDMNOPIJKL

-- mecej4

[Rafik Zurob]

It's really easy to delete a file in Fortran if you have the file open.
Just close it with status="delete".

e.g. close(10, status='delete')

Regards

Rafik

"Clive Page" <use...@page2.eu> wrote in message
news:9qsofj...@mid.individual.net...

[Terence]

For me, my F77 compilers won't accept POSITION and ADVANCE as valid
keywords.
Nor PRINT as a valid i/o instruction, (which I changet to WRITE(*, .

Then the program compiled but the execution failed on seeking file XXX.
After defining that as STATUS='NEW', the programs compiled and executed and
gave output result:-
NOP

Compiler: good old reliable MS V 3.31 of 1985 (and I've got three later ones
I don't seem to ever need, or really trust).

[David Duffy]

robert....@oracle.com wrote:
> I am interested in knowing what the following program prints using
> various compilers.

/opt/open64-5.0/bin/openf95

ABCDMNOPIJKL

[Terence]

I should have added that the file XXX in my experiment, contains "MNOP" as
the final result, and since the output to screen in F77 of 1985, the first
characteroutput is treated as a screen control character, the leading "M" is
not shown.

So the file contains MNOP and the treatement as given by PRINT of Fortran I
and II an F66 would have given MNOP, but using the screen gave me NOP as
first indicated.

[Richard Maine]

Rafik Zurob <nos...@hotmail.com> wrote:

> It's really easy to delete a file in Fortran if you have the file open.
> Just close it with status="delete".
>
> e.g. close(10, status='delete')

Yes, but that "if you have the file open" can be a significant
condition. If you don't have the file open, and you don't know details
about the file, you can find it difficult to open on some systems.

That's particularly so for older systems and pre-f2003 versions of the
language. With f2003 and most current systems, I'd think you would have
pretty good odds of being able to open most files as unformatted stream
(provided you have appropriate permissions). In older systems and older
versions of the language, you could sometimes find that you could not
sucessfully open a file without knowing the right combination of
formatted/unformatted and sequential/direct.

I've been bitten by variants of that problem, though mostly that was in
aplications where I wanted to rewrite the file instead of just delete
it. I was thankful for the status='replace' added in f90. Hmm. It hadn't
ocurred to me, but that could provide somewhat of a workaround. Open the
file with status='replace'. That should delete the old file and create a
new one. Then you could close with status='delete'. Seems like it ought
to have worked and be standard conforming (again, assuming the necessary
permissions). But I've tended to go with system-dependent alternatives
in this case. And I've yet to see an f2003 compiler, though admitedly, I
have seen plenty of f95 compilers with the f2003 stream feature. (Yes, I
know f2003 compilers are aleged to exist, but that's not the same thing
as me seeing one.)

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

[robert....@oracle.com]

On Feb 25, 7:59 am, Sebastian Hanigk <sebastian.han...@fs.tum.de>
wrote:

The latest release of Oracle Solaris Studio Fortran produces
the same bad output.

Bob Corbett

[robert....@oracle.com]

On Feb 25, 10:43 am, Clive Page <use...@page2.eu> wrote:

As Rafik Zurob pointed out, it is usually easy to delete a file when
the connection is closed. I should have modified my test program to
have it clean up after itself.

Bob Corbett

[robert....@oracle.com]

On Feb 25, 11:56 am, mecej4 <do...@email.me> wrote:

> -- mecej4- Hide quoted text -
>
> - Show quoted text -

Good job!

Bob Corbett

[Athanasios Migdalas]

Here are my finds from 7 different compilers running on a SuSE machine
x86_64 with an old kernel 2.6.31.14-0.8-desktop:

(1) GNU Fortran (GCC) 4.6.3 20120127 (prerelease)
ABCDMNOP

(2) GNU Fortran (GCC) 4.7.0 20120218 (experimental)
ABCDMNOP

(3) Lahey/Fujitsu Linux64 Fortran Compiler Release L8.00a
ABCDMNOP

(4) ifort (IFORT) 12.0.0 2010111
ABCDEFGHIJKL

(5) f90: Sun Fortran 95 8.6 Linux_i386 2011/11/16
MNOP

(6) OpenUH/Open64 Compiler Suite: Version 4.2
Built on: 2011-11-16 11:00:41 -0600
ABCDMNOPIJKL

(7) G95 (GCC 4.0.3 (g95 0.92!) Jun 24 2009)
ABCDEFGHIJKL

--
A.M.

[Athanasios Migdalas]

Of the 7 compilers I tested only the OpenUH produces the anticipated result.

--
A.M.

[Clive Page]

On 25/02/2012 23:02, Richard Maine wrote:
> Hmm. It hadn't
> ocurred to me, but that could provide somewhat of a workaround. Open the
> file with status='replace'. That should delete the old file and create a
> new one. Then you could close with status='delete'.

That's an ingenious solution, Richard. I hadn't thought of that.


--
Clive Page

[Tobias Burnus]

robert....@oracle.com wrote:
> On Feb 25, 1:53 am, Clive Page<use...@page2.eu> wrote:
>> On 25/02/2012 06:38, robert.corb...@oracle.com wrote:
>>> I am interested in knowing what the following program prints using
>>> various compilers.
>>

>> [...] Using nagfor release 5.2(721) on Linux:

>>
>> ABCDMNOP
>>
>> I'd be interested to know what you think standard behavior should produce.
>

> According to interpretation 000024 of the Fortran 95 standard [...]

>
> The corresponding statement in the Fortran 2008 standard is
> paragraph 2 of Clause 9.3.4.2. Based on that statement and
> on paragraph 4 of non-normative Clause C.6.2 of the
> Fortran 2008 standard, my reading is that the output should
> be
>
> ABCDMNOPIJKL

I don't agree. Looking at 9.3.4.2, I believe that NAG's output is
correct: "ABCDMNOP" + end-record marker + endfile marker.

I concur, however, that the nonnormative C.6.2 implies the
"ABCDMNOPIJKL" plus end-record marker plus endfile marker. However, as
that's not normative, I will go for the "ABCDMNOP".


Side question: Where can one find the IR 000024? I quickly searched for
it, but I couldn't find it on the J3 and wg5 page.

Side remark: Looking at the produced file is more illustrative than
looking at the 12-character string. For instance, gfortran has a similar
output as NAG, but it lacks the new line, which 9.3.4.2 mandates. Or
g95: It appends a " MNOP" line after the "ABCDEFGHIJKL" line.


Quotes from the Fortran 2008 standard:

Paragraph 2 of Clause 9.3.4.2 has the following:

"A nonadvancing input/output statement may position a record file at a
character position within the current record, or a subsequent record
(10.8.2). Using nonadvancing input/output, it is possible to read or
write a record of the file by a sequence of input/output statements,
each accessing a portion of the record. It is also possible to read
variable-length records and be notified of their lengths. If a
nonadvancing output statement leaves a file positioned within a current

record and no further output statement is executed for the file before
it is closed or a BACKSPACE, ENDFILE, or REWIND statement is executed

for it, the effect is as if the output statement were the corresponding
advancing output statement."

Fortran 2008's C.6.2, paragraph 4 (nonnormative):

"If the next I/O operation on a file after a nonadvancing write is a
rewind, backspace, end file or close operation, the file is positioned
implicitly after the current record before an ENDFILE record is written
to the file, that is, a REWIND, BACKSPACE, or ENDFILE statement
following a nonadvancing WRITE statement causes the file to be
positioned at the end of the current output record before the endfile
record is written to the file."

Tobias

[Tobias Burnus]

Tobias Burnus wrote:
> Side question: Where can one find the IR 000024? I quickly searched for
> it, but I couldn't find it on the J3 and wg5 page.

I found it: http://j3-fortran.org/doc/year/02/02-006c2.txt

From the answer and the question, I just deduce that a line break
(record marker) must be written. It leaves kind of open whether the
"IJKL" from a previous write should be there or whether the record
marker should be directly written after the current position, i.e.
before the "IJKL" of the first write. In this regard, I find Fortran
2008's C.6.2 is actually more confusing that the normative text in
9.3.4.2 itself.

> Side remark: Looking at the produced file is more illustrative than
> looking at the 12-character string. For instance, gfortran has a similar
> output as NAG, but it lacks the new line, which 9.3.4.2 mandates.

Actually, gfortran's output doesn't differ to NAG's. (Or rather: The is
*no* newline *before* the rewind is executed, only after the
"rewind(10)", but that's fine. On needs to be careful where on places a
'call system ("cat XXX")' ...)

Tobias

[Dan Nagle]

Hello,

On 2012-02-26 11:39:14 +0000, Tobias Burnus said:

>
> I found it: http://j3-fortran.org/doc/year/02/02-006c2.txt

You seem to have answered your own question.

There are several versions of 006, 006a is active (in the pipeline
somewhere), the 006c<n> versions are the interpretations
that form the basis of Corrigendum <n>.

--

Cheers!
Dan Nagle

[Andrew Mai]

xlf90 on Power6 IBM:

MNOP

[robert....@oracle.com]

On Feb 26, 2:19 am, Tobias Burnus <bur...@net-b.de> wrote:

> robert.corb...@oracle.com wrote:
> > On Feb 25, 1:53 am, Clive Page<use...@page2.eu>  wrote:
> >> On 25/02/2012 06:38, robert.corb...@oracle.com wrote:
> >>> I am interested in knowing what the following program prints using
> >>> various compilers.
>
> >> [...] Using nagfor release 5.2(721) on Linux:
>
> >> ABCDMNOP
>
> >> I'd be interested to know what you think standard behavior should produce.
>
> > According to interpretation 000024 of the Fortran 95 standard  [...]
>
> > The corresponding statement in the Fortran 2008 standard is
> > paragraph 2 of Clause 9.3.4.2.  Based on that statement and
> > on paragraph 4 of non-normative Clause C.6.2 of the
> > Fortran 2008 standard, my reading is that the output should
> > be
>
> > ABCDMNOPIJKL
>
> I don't agree. Looking at 9.3.4.2, I believe that NAG's output is
> correct: "ABCDMNOP" + end-record marker + endfile marker.

After the first READ statement is executed, the file
consists of two records: a formatted record that is the
sequence of characters "ABCDEFGHIJKL" followed by an
endfile record. The file position is within the first
record between the characters D and E.

After the second WRITE statement is executed, the file
consists of one record: a formatted record that is the
sequence of characters "ABCDMNOPIJKL". The file position
is within the record between the characters P and I. See
paragraph 4 of Clause 9.3.4.3 and the last sentence of
paragraph 4 of Clause 9.3.4.4.

If the second WRITE statement had not specified nonadvancing
output, the file would consist of the same record, but the file
position would be after the record, not within the record. See
paragraph 5 of Clause 9.3.4.4. The fourth sentence of the
second paragraph of Clause 9.3.4.2 states

If a nonadvancing output statement leaves a file
positioned within a current record and no further
output statement is executed for the file before
it is closed or a BACKSPACE, ENDFILE, or REWIND
statement is executed for it, the effect is as if

the output were the corresponding advancing output
statement.

Therefore, after the second REWIND statement is executed, the
file consists of two records: A formatted record that is the
sequence of characters "ABCDMNOPIJKL" followed by an endfile
record. The file position is before the first record.

When the second READ statement is executed the variable STR
is set to "ABCDMNOPIJKL".

Robert Corbett

[stan]

I was looking at this over breakfast and I don't think I agree with
your your interpretation. Here's how I read the above:

event1: nonadvancing output statement leaves file in record

event2: possibly non output statement not including
close, backspace, endfile, rewind

event3: close, backspace, endfile, or rewind statement

the resulting effect is the same as if event1 were an advancing output
or IOW the nonadvancing act like advancing in this scenario

> Therefore, after the second REWIND statement is executed, the
> file consists of two records: A formatted record that is the
> sequence of characters "ABCDMNOPIJKL" followed by an endfile
> record. The file position is before the first record.

Based on my reading above I'd say an advancing output would have left

ABCDMNOP + EOR + EOF in 'XXX' at this point as a result of effective
advancing output.

I should also state for the record I'm not typically a standards
language lawyer type. Generally reading standards makes my head hurt,
but I believe they are necessary and generally a good thing. I just
wish someone would make a movie or cliffs notes so I could avoid such
a really dark place.

[robert....@oracle.com]

> or IOW the nonadvancing act like advancing in this scenario.

I agree that the program should produce the same output regardless
of whether value of the ADVANCE= specifier in the second WRITE
statement is YES or NO. In either case, the formatted record
should be the sequence of characters "ABCDMNOPIJKL".

>
> > Therefore, after the second REWIND statement is executed, the
> > file consists of two records:  A formatted record that is the
> > sequence of characters "ABCDMNOPIJKL" followed by an endfile
> > record.  The file position is before the first record.
>
> Based on my reading above I'd say an advancing output would have left
>
> ABCDMNOP + EOR + EOF in 'XXX' at this point as a result of effective
> advancing output.

Where does the standard grant a processor permission to chop off the
last four characters of the formatted record?

Bob Corbett

[robert....@oracle.com]

On Feb 28, 3:45 pm, robert.corb...@oracle.com wrote:
>
> Where does the standard grant a processor permission to chop off the
> last four characters of the formatted record?

The standard does not say that the last character written is the last
character in the record being written. Consider the program

PROGRAM MAIN
CHARACTER*12 STR
OPEN (10, FILE='YYY')
WRITE (10, '(A, TL8, A)') 'ABCDEFGHIJKL', 'MNOP'

REWIND 10
READ (10, '(A)') STR

CLOSE (10, STATUS='DELETE')

PRINT '(A)', STR
END

The output of this program should be

ABCDMNOPIJKL

Bob Corbett

[Richard Maine]

<robert....@oracle.com> wrote:

[after a non-advancing sequential overwrite of something shorter than
the original record]

> Where does the standard grant a processor permission to chop off the
> last four characters of the formatted record?

Hmm. I was tempted to answer off the top of my head, but knowing that
much about Bob, I figured I better read those bits of the standard very
carefully instead.

For stream output, I find it "clear as day" (to me, anyway). F2003
9.2.3.3:

"For a formatted tream output statement, if no error condition occurred,
the terminal point of the file is set to the highest-numbered position
to which data was transferred by the statement."

But for sequential, I admit I can't find it unambiguously stated. My
mental model is much like that of the stream case - that everything
after what was last written is gone. It is clear enough (to me) that all
subsequent records get "chopped", but I admit I can't find the standard
quite saying what happens to the current record. The standard says that
the file is positioned to the end of the current record, but that
doesn't quite tell me where that end is. I'd have said that it isn't so
much that the last characters are "chopped off" as that they just
weren't written. You are, after all, writing a new record. That it
happens to be where the old record used to be shouldn't matter. But I
can't find that unambiguously stated.

It is also a little confused by the fact that you can read the first
part of the old record (with non-advancing input) and then write the
rest, so that does get part of the old record. (Anyway I think you can
do that.) In that case, at east part of what was in the old record does
matter, muddying the waters.

[stan]

robert....@oracle.com wrote:
> On Feb 28, 9:45 am, stan <smo...@exis.net> wrote:

<snip>

I didn't check the standard and I bow to your knowledge and
experience; I have no helpful answer to your question.

My understanding goes something like this for advancing output.

write(*,'(a)') "some text"

will write "some text" + eor

or IOW a whole record. So the write statement in the current context
will start writing at the current file position and write a whole
record. With the advance parameter rendered moot this seems just like
a standard advancing write and this is confusing me. Are you saying
because we start writing in the middle of an existing record an
advancing write should do something different than if it was simply
writing any other record? Would this be true in all cases or only the
current context?

That seems to me like different behavior from what I expect of a
normal advancing write, or at least like a special case of
behavior. Normally I would head off to do some reading, but this seems
to have the big guns scratching heads so my chances of finding an
answer seem remote.

[glen herrmannsfeldt]

Richard Maine <nos...@see.signature> wrote:

(snip)

> It is also a little confused by the fact that you can read the first
> part of the old record (with non-advancing input) and then write the
> rest, so that does get part of the old record. (Anyway I think you can
> do that.) In that case, at east part of what was in the old record does
> matter, muddying the waters.

To me, that means that on record-oriented systems that the
Fortran I/O system will read in the record, modify it as
appropriate, and write it out.

On stream-oriented systems, like Unix, the OS disk buffering
system has to keep track of partial block writes.

-- glen

[Richard Maine]

stan <smo...@exis.net> wrote:

> My understanding goes something like this for advancing output.
>
> write(*,'(a)') "some text"
>
> will write "some text" + eor
>
> or IOW a whole record. So the write statement in the current context
> will start writing at the current file position and write a whole
> record. With the advance parameter rendered moot this seems just like
> a standard advancing write and this is confusing me. Are you saying
> because we start writing in the middle of an existing record an
> advancing write should do something different than if it was simply
> writing any other record? Would this be true in all cases or only the
> current context?
>
> That seems to me like different behavior from what I expect of a
> normal advancing write, or at least like a special case of
> behavior. Normally I would head off to do some reading, but this seems
> to have the big guns scratching heads so my chances of finding an
> answer seem remote.

That seems like an excellent point. The nonadvancing stuff just
complicates the point. Go back to the simplest case, as Stan shows.
Though I couldn't find it quite explicit in the standard, I'm *SURE*
that there would be lots of majorly pissed users if the program

program bad
open(10,file='xxx')
write (10,'(a)') "some text"
end

ended up with a file that had additional stuff after the "some text"
just because there was a file with other content before this program
ran. (Status='replace' would be a better way to do this, but I know lots
of users don't code that way, particularly as status='replace' was new
to f90). I'm sure enough of that to say that if the standard does allow
it, that would get fixed as a bug in the standard before any vendors
would change their compilers to act like that.

Just as a sanity check (and a typo check), I ran that program with both
compilers convenient to me at the moment. Both of them ended up with
just "some text", even though the file started out with "some text and
some more".

[Ron Shepard]

In article <1kg6the.8shhg810gpor8N%nos...@see.signature>,
nos...@see.signature (Richard Maine) wrote:

[...]

> program bad
> open(10,file='xxx')
> write (10,'(a)') "some text"
> end
>
> ended up with a file that had additional stuff after the "some text"
> just because there was a file with other content before this program
> ran. (Status='replace' would be a better way to do this, but I know lots
> of users don't code that way, particularly as status='replace' was new
> to f90). I'm sure enough of that to say that if the standard does allow
> it, that would get fixed as a bug in the standard before any vendors
> would change their compilers to act like that.
>
> Just as a sanity check (and a typo check), I ran that program with both
> compilers convenient to me at the moment. Both of them ended up with
> just "some text", even though the file started out with "some text and
> some more".

I don't know which systems you checked this on, but it may not be as
clear and unambiguous as you might think. If you are using a unix
system, for example, then do an "ls -l xxx" to look at the file
size. You may see that the size reported is consistent with the
original longer file rather than the shorter modified file. This
behavior is, I think, one of the reasons that status='replace' was
added to the fortran standard.

$.02 -Ron Shepard

[Richard Maine]

Yes, this system is a Unix one (OS X). No, I don't observe the behavior
you describe from ls -l.

I have trouble imagining it as well. The Fortran standard is very clear
that writing a record to a sequential file gets rid of all subsequent
records. If an implementation doesn't do that, it is just broken. The
only place I see even possibly a question is for the rest of what used
to be the same record. But I don't see how that has much to do with Unix
file system issues. I'm guessing you might be thinking of issues
relating to file truncation, but those aren't going to be a function of
record boundaries.

And as Unix doesn't have a convention for indicating and end-of-file, I
don't see how you are going to have ls -l show something longer than is
"visible". The closest thing to that would be to pad the rest of the
file with achar(0) characters, but that would have some awkward effects,
and would also take active rewriting.

Also, the standard is explicit (and I quoted that part) about the
truncation happening for formatted stream output. Since formatted stream
output is modeled very much on C (and thus on Unix), I'd expect it to
match pretty well with how the Unix file system works.

My picture of status='replace' was for other issues, one at least
somewhat related. If you open a file with status='unknown' and start
reading without ever first writing, you can accidentally get the old
contents instead of the immediate end-of-file that someone might have
expected if they didn't think about the possibility of an existing file.
But I think that as soon as you write something, that issue goes away.
The other issue that I'm aware of is that without status='replace', you
might not be able to open an arbitrary pre-existing file at all (and
thus can't delete it purely from within Fortran either).

[glen herrmannsfeldt]

Richard Maine <nos...@see.signature> wrote:
(snip)

>> > Just as a sanity check (and a typo check), I ran that program with both
>> > compilers convenient to me at the moment. Both of them ended up with
>> > just "some text", even though the file started out with "some text and
>> > some more".

>> I don't know which systems you checked this on, but it may not be as
>> clear and unambiguous as you might think. If you are using a unix
>> system, for example, then do an "ls -l xxx" to look at the file
>> size. You may see that the size reported is consistent with the
>> original longer file rather than the shorter modified file. This
>> behavior is, I think, one of the reasons that status='replace' was
>> added to the fortran standard.

There might be cases where directories do that, but not files.

> Yes, this system is a Unix one (OS X). No, I don't observe
> the behavior you describe from ls -l.

It seems to me that this goes back to the tape days. The way
most tapes are written, you can position the tape (always
to a block boundary) and start writing. As the hardware
isn't designed to position accurately enough, and you might
write a different size block, data after that point can't
reliably expected to be readable. Systems are designed to
write an EOF at that point.

Some systems will let you read past the EOF marker. If you
accidentally overwrite the beginning of a file, you might
recover the end that way, usually after an error reading
a partial block. The DDS (4mm, DAT) tape system was designed
not to let you do that. There are stories that you can start
writing to the tape, unplug the drive while writing, without
letting it write the EOF, and then recover data past that point.
I never tried it, though.

> I have trouble imagining it as well. The Fortran standard is
> very clear that writing a record to a sequential file gets
> rid of all subsequent records. If an implementation doesn't
> do that, it is just broken. The only place I see even possibly
> a question is for the rest of what used to be the same record.

Yes, that is usual, for most systems and most languages.

> But I don't see how that has much to do with Unix file
> system issues.

For some systems, the hardware won't allow much else. I believe
for unix, the I/O library routines do ftruncate() on the file
to actually do it. Some unix I/O calls work the same as for
direct access I/O, and so wouldn't naturally truncate.

> I'm guessing you might be thinking of issues relating to file
> truncation, but those aren't going to be a function of
> record boundaries.

> And as Unix doesn't have a convention for indicating and
> end-of-file, I don't see how you are going to have ls -l
> show something longer than is "visible".

It might be that VMS could do that. I do remember that VMS shows
the blocks allocated to the file, and that blocks are allocated
in clusters. You see that in the appropriate DIR command.
Unix hides such blocking from the user.

> The closest thing to that would be to pad the rest of the
> file with achar(0) characters, but that would have some
> awkward effects, and would also take active rewriting.

I just noticed that if you call ftruncate() with a length
longer than actually written, that the file is logically
extended to that length. On most, the file isn't physically
extended, and the system will read achar(0) up to EOF.
(Many allow for unallocated holes in a file that will read
as achar(0).)

> Also, the standard is explicit (and I quoted that part)
> about the truncation happening for formatted stream output.
> Since formatted stream output is modeled very much on C
> (and thus on Unix), I'd expect it to match pretty well
> with how the Unix file system works.

-- glen

[tho...@antispam.ham]

robert....@oracle.com writes:

> Where does the standard grant a processor permission to chop off the
> last four characters of the formatted record?

Is it valid to ask the question "Where does the standard deny a

processor permission to chop off the last four characters of the
formatted record?"

I'm thinking in terms of processors being allowed to start
World War III under certain circumstances, so why not chop
off characters? But more to the point, given that the
standard doesn't prevent vendors from provide extensions,
it seems like the standard doesn't necessarily need to
grant things to allow those things to be done. If the
standard prohibits it, then that's a different matter.

[tho...@antispam.ham]

robert....@oracle.com writes:

> I am interested in knowing what the following program prints using
> various compilers.

Out of curiosity, is this just an academic exercise in fixing
holes in the standard, or is there a real customer doing such
things in their code?

[mecej4]

Bob Corbett is a well-respected senior compiler architect/developer. He
had been with Sun for a number of years, and is currently with Oracle
(Oracle bought Sun a couple of years ago).

I gather from his post here that an Oracle Fortran user pointed out this
bug in the Sun Fortran compilers for Solaris and/or Linux. Even though
the compilers are "free", support has to be paid for, so the customer is
probably "real".

-- mecej4

[Richard Maine]

mecej4 <mecej4...@operamail.com> wrote:

> On 2/29/2012 9:39 AM, tho...@antispam.ham wrote:
> > robert....@oracle.com writes:
> >
> >> I am interested in knowing what the following program prints using
> >> various compilers.
> >
> > Out of curiosity, is this just an academic exercise in fixing
> > holes in the standard, or is there a real customer doing such
> > things in their code?
> >
> Bob Corbett is a well-respected senior compiler architect/developer. He
> had been with Sun for a number of years, and is currently with Oracle
> (Oracle bought Sun a couple of years ago).

And before that was with Elxsi, where I met him in 1984.

> I gather from his post here that an Oracle Fortran user pointed out this
> bug in the Sun Fortran compilers for Solaris and/or Linux. Even though
> the compilers are "free", support has to be paid for, so the customer is
> probably "real".

Besides being speculation, that doesn't actually answer the question.
Just because a customer is "real" doesn't mean that he is actually doing
such things in his or her code. Real customers also experiment with
compilers to try to find holes or just to understand things. Just
because a customer submits a bug report doesn't mean he or she has real
code that hits the bug. I know, as I've been such a customer doing such
experiments and submitting such bug reports.

Might well be a customer with such code. I don't know. But I don't think
you have any evidence either.

I am very sure that there are customers who depend on the behavior of
the simple case brought up by Stan, though. I've seen code that depends
on acting "correctly" for that case. In the dim past, I'm pretty sure I
wrote such code.

[glen herrmannsfeldt]

tho...@antispam.ham wrote:
> robert....@oracle.com writes:

>> Where does the standard grant a processor permission to chop
>> off the last four characters of the formatted record?

> Is it valid to ask the question "Where does the standard deny a
> processor permission to chop off the last four characters of the
> formatted record?"

If you are writing to a file system with fixed length records,
then they will naturally be chopped of at the record length.

The choices would seem to be to ignore the problem, or generate
an I/O error. With fixed length records, it is usual to pad
shorter records out to the record length, though I don't know
if that is explicitly written into the standard.

-- glen

[stan]

IMHO, Bob has street cred and if he asks then the question is
legit. He knows a lot more than me about the standard and the behavior
he expects would surprise me so I offered my ideas.

As for the question at hand, the fact that both users and existing
compilers don't agree makes it clear that this is one of those
opportunities to improve both the standard (theoretical) and the
practical (implemented in real compilers) understanding of Fortran IO;
I'd like to see this run to ground.

I've used advancing and nonadvancing output so this doesn't feel like
a corner case to me, although I've never tried to do what Bob
expects. Apparently I didn't run into a problem because gfortran does
what I expect, or more likely I expect the results I do because that's
what I normally see.

If I were to use one of the other compilers that does something
different I would be prone to writing code that blows up and that
would cut into my pub time and that would cause me to want to send
rude remarks to people like Bob ;)

[Richard Maine]

Extensions are not relevant here. You can't just take any random
compiler (mis)feature and call it an extension in order to avoid calling
it a bug. The "certain circumstances" under which a compiler is allowed
to start WWIII involve code that violates the standard. (Or, of course,
the compiler could start WWIII with standard-conforming code if that's
actually what the code specifies).

Most of the standard isn't written either in terms of what a compiler
must do or must not do. Most of the standard just describes what a
standard conforming program looks like and what results such a program
has. The main requirements on compilers are in a pretty short section up
front, which I will greatly abbreviate as saying that a compiler has to
give the results specified by the standard for a standard-conforming
program. There are a few extra requirements, and a few outs, but that's
the central part of the specification.

In order to count as an extension, you have to start with code that
violates the standard. The extension can then give meaning to particular
cases of standard violation. If the code conforms to the standard, then
the compiler has to do what the standard says (with a few outs, such as
exceeding size or cioplexity limits).

If the code conforms to the standard, but the standard doesn't establish
a meaning, then that sometimes counts as just an implementation choice
instead of an extension. Other times, it is just a hole in the standard,
as I at least somewhat suspect here. If so, that's what interpretation
requests are for.

Of course, after all this, someone might come along and find that the
standard does specify the behavior here. I didn't find the
specification, but I could possibly have missed it. Stranger things have
happened.

[Tobias Burnus]

Richard Maine wrote:
> That seems like an excellent point. The nonadvancing stuff just
> complicates the point. Go back to the simplest case, as Stan shows.
> Though I couldn't find it quite explicit in the standard, I'm *SURE*
> that there would be lots of majorly pissed users if the program
>
> program bad
> open(10,file='xxx')
> write (10,'(a)') "some text"
> end
>
> ended up with a file that had additional stuff after the "some text"
> just because there was a file with other content before this program
> ran.

Well, that example is easier as there is no nonadvancing read involved -
and as the file is closed with termination of the program.

Besides the issue of nonadvancing read, I think it is also interesting
to see the result of the file after a FLUSH but before actually closing
it. With keeping a file open while accessing it from a different
program, I presumably leave the solid ground, but users do write such
codes. (At least on Unix, it is common that multiple programs access the
same file.)


The following program can be run in 8 different ways:

* With a (nonadvancing) READ - and without READ
* With advancing or nonadvancing WRITE
* With sequential or with stream I/O

Especially the result after the FLUSH but before closing (or REWIND or
ENDFILE) widely varies between different compilers.


Here is the program as I posted to the J3 mailing list
[The access='stream' was later suggested by Rafik, who also provided the
IBM xlf and gfortran/cygwin results.]

!--------------------------------------------------------
OPEN (10, FILE='XXX', status='replace')
WRITE(10, '(a)') 'ABCDEFGHIJKL'
WRITE(10, '(a)') '1234567890ab'
close (10)

OPEN (10, FILE='XXX', position='REWIND', status='old', &
action='readwrite', access='sequential', form='formatted')
! READ(10, '(tl1)', advance='no') ! << add optionally
WRITE (10, '(A)', ADVANCE='NO') 'mnop' ! << optionally: advance='yes'
FLUSH (10)
call execute_command_line ('cat XXX; echo "<"')
close(10)
call execute_command_line ('cat XXX; echo "<"')
end
!--------------------------------------------------------


(Replace "flush(10)" by "call flush(10)" and "execute_command_line"
by "system" if your compiler supports those instead of the new
F2003 statement/F2008 intrinsic. On Windows, the "cat" could be
replaced by "type". I had to do some of those for the results below.)


Results for several compilers:


a) Nonadvancing READ, nonadvancing WRITE
----------------------------------------

(i) Pathscale 3.2.99, Cray 7.1, Open64 4.2

mnopEFGHIJKL
1234567890ab
<
mnopEFGHIJKL
<


(ii) gfortran 4.7, PGI 11.5,

mnop<
mnop
<


(iii) g95 0.93, sunf95 8.3

ABCDEFGHIJKL
mnop<
ABCDEFGHIJKL
mnop<


(iv) ifort 12.1 [also with "-assume nobuffered_io"]

ABCDEFGHIJKL
1234567890ab
<
ABCDEFGHIJKL
mnop
<


(v) IBM XL Fortran

mnop<
mnop<

(iv) NAG f95 5.1

ABCDEFGHIJKL
mnop567890ab
<
ABCDEFGHIJKL
mnop
<


b) Nonadvancing READ, advancing WRITE
-------------------------------------

(i) Pathscale 3.2.99, Cray 7.1, Open64 4.2

mnopEFGHIJKL
1234567890ab
<
mnopEFGHIJKL
<


(ii) gfortran 4.7, PGI 11.5, IBM XL Fortran

mnop
<
mnop
<


(iii) g95 0.93, ifort 12.1, sunf95 8.3

ABCDEFGHIJKL
mnop
<
ABCDEFGHIJKL
mnop
<

(iv) NAG f95 5.1

ABCDEFGHIJKL
mnop
67890ab
<
ABCDEFGHIJKL
mnop
<


c) No READ, nonadvancing WRITE
------------------------------

(i) Pathscale 3.2.99, Cray 7.1, Open64 4.2, NAG f95 5.1

mnopEFGHIJKL
1234567890ab
<
mnop
<


(ii) gfortran 4.7, PGI 11.5,

mnop<
mnop
<


(iii) g95 0.93, IBM XL Fortran, sunf95 8.3

mnop<
mnop<


(iv) ifort 12.1 [-assume nobuffered_io]

ABCDEFGHIJKL
1234567890ab
<
mnop
<


d) No READ, advancing WRITE
------------------------------

(i) Pathscale 3.2.99, Cray 7.1, Open64 4.2, NAG f95 5.1

mnop
FGHIJKL
1234567890ab
<
mnop
<


(ii) gfortran 4.7, PGI 11.5, g95, ifort 12.1, IBM XL Fortran, sunf95 8.3

mnop
<
mnop
<


------------------------------------------------
With stream access instead of sequential access:
------------------------------------------------

a) Nonadvancing READ, nonadvancing WRITE
----------------------------------------

(i) IBM XL Fortran, g95 0.93, sunf95 8.3

mnopEFGHIJKL
1234567890ab
<
mnopEFGHIJKL
1234567890ab
<

(ii) gfortran 4.5.3 (cygwin)/4.7(Linux)

mnopEFGHIJKL
1234567890ab
<
mnop
FGHIJKL
1234567890ab
<

(iii) NAG f95 5.1, ifort 12.1

ABCDEFGHIJKL
mnop567890ab
<
ABCDEFGHIJKL
mnop
<


b) Nonadvancing READ, advancing WRITE
-------------------------------------

(i) IBM XL Fortran, g95 0.93

mnop
FGHIJKL
1234567890ab
<
mnop
FGHIJKL
1234567890ab
<

(ii) gfortran 4.5.3 (cygwin)

mnop
<
mnop
<

(iii) gfortran 4.7(Linux)

ABCDEFGHIJKL
1234567890ab
<
ABCDEFGHIJKL
mnop
67890ab
<


(iv) sunf95 8.3
ABCDEFGHIJKL
mnop567890ab
<
ABCDEFGHIJKL
mnop567890ab
<

(v) NAG f95 5.1

ABCDEFGHIJKL
mnop
67890ab
<
ABCDEFGHIJKL
mnop
<

(vi) ifort 12.1

ABCDEFGHIJKL
mnop
<
ABCDEFGHIJKL
mnop
<


c) No READ, nonadvancing WRITE
------------------------------

(i) IBM XL Fortran, g95 0.93, sunf95 8.3

mnopEFGHIJKL
1234567890ab
<
mnopEFGHIJKL
1234567890ab
<

(ii) gfortran 4.5.3 (cygwin)/4.7(Linux)

mnopEFGHIJKL
1234567890ab
<
mnop
FGHIJKL
1234567890ab
<

(iii) NAG f95 5.1

mnopEFGHIJKL
1234567890ab
<
mnop
<

(iv) ifort 12.1

ABCDEFGHIJKL
1234567890ab
<
mnop
<



d) No READ, advancing WRITE
------------------------------

(i) IBM XL Fortran, sunf95 8.3

mnop
FGHIJKL
1234567890ab
<
mnop
FGHIJKL
1234567890ab
<

(ii) gfortran 4.5.3 (cygwin)/4.7(Linux), g95 0.93, ifort 12.1

mnop
<
mnop
<

(iii) NAG f95 5.1

mnop
FGHIJKL
1234567890ab
<
mnop
<


Tobias

[stan]

Tobias Burnus wrote:
> Richard Maine wrote:
>> That seems like an excellent point. The nonadvancing stuff just
>> complicates the point. Go back to the simplest case, as Stan shows.
>> Though I couldn't find it quite explicit in the standard, I'm *SURE*
>> that there would be lots of majorly pissed users if the program
>>
>> program bad
>> open(10,file='xxx')
>> write (10,'(a)') "some text"
>> end
>>
>> ended up with a file that had additional stuff after the "some text"
>> just because there was a file with other content before this program
>> ran.
>
> Well, that example is easier as there is no nonadvancing read involved -
> and as the file is closed with termination of the program.
>
> Besides the issue of nonadvancing read, I think it is also interesting
> to see the result of the file after a FLUSH but before actually closing
> it. With keeping a file open while accessing it from a different
> program, I presumably leave the solid ground, but users do write such
> codes. (At least on Unix, it is common that multiple programs access the
> same file.)

<neat results or chaos, I'm not sure snipped>

Wow, I don't think I understand many of those results.

Doesn't the FLUSH output statement create a context different from
9.3.4.2? If CLOSE replaces FLUSH then "the effect is as if the output
were the corresponding advancing output" but with the FLUSH it seems
like the advance='no' is in play and creates uncharted territory; from
my reading. There's a good chance I'm missing something but from the
results I'd say I'm in good company.

[robert....@oracle.com]

On Feb 29, 7:39 am, tho...@antispam.ham wrote:

I did not and do not think there are holes in the Fortran 2008
standard regarding the issues illustrated by the program I
included in the first post in this thread.

I recently started work on fixing Oracle Solaris Studio
Fortran's handling of nonadvancing I/O in response to a change
request (CR) filed for a user. The example in the CR is not as
complex as the program I included in my posting. I wrote that
program to test many features of nonadvancing I/O with a single
program. I wrote and ran other test programs before I produced
that program. I have included slightly modified versions of a
couple of those programs below.

Bob Corbett

------------------------------

PROGRAM MAIN
CHARACTER*12 STR
OPEN (10, FILE='YYY', POSITION='REWIND')
WRITE (10, '(A)') 'ABCDEFGHIJKL'
REWIND(10)
WRITE (10, '(TR4)', ADVANCE='NO')
WRITE (10, '(TL2, A)', ADVANCE='NO') 'MNOP'

REWIND 10
READ (10, '(A)') STR
CLOSE (10, STATUS='DELETE')
PRINT '(A)', STR
END

--------------------------------

PROGRAM MAIN
CHARACTER*12 STR
OPEN (10, FILE='YYY', POSITION='REWIND')
WRITE (10, '(A, TL8)', ADVANCE='NO') 'ABCDEFGHIJKL'
WRITE (10, '(A)', ADVANCE='NO') 'MNOP'

REWIND 10
READ (10, '(A)') STR
CLOSE (10, STATUS='DELETE')
PRINT '(A)', STR
END

---------------------------------

[robert....@oracle.com]

Note 9.58 says "the exact meaning of the flush operation is not
precisely defined."

Bob Corbett

[robert....@oracle.com]

On Feb 29, 10:01 pm, robert.corb...@oracle.com wrote:
> On Feb 29, 7:39 am, tho...@antispam.ham wrote:
>
> > robert.corb...@oracle.com writes:
> > > I am interested in knowing what the following program prints using
> > > various compilers.
>
> > Out of curiosity, is this just an academic exercise in fixing
> > holes in the standard, or is there a real customer doing such
> > things in their code?
>
> I did not and do not think there are holes in the Fortran 2008
> standard regarding the issues illustrated by the program I
> included in the first post in this thread.

Some might wonder, if I thought I knew what the standard requires,
why did I post the program to this news group? When I started
work on fixing the bugs in nonadvancing I/O for Oracle Solaris
Studio Fortran, I quickly discovered that the fix was going to
require a lot of work. That made me wonder if other
implementations implemented nonadvancing I/O as I understand the
Fortran standard to require. The posting was the result of my
curiosity.

Bob Corbett

[robert....@oracle.com]

The number of records the file will contain after the
WRITE statement is executed depends on the file position
after the OPEN statement is executed. Because the OPEN
statement does not contain a POSITION= specifier, the
file position after the OPEN statement is executed is
unspecified. It might be at the start of the file, at
the end of the file, or anywhere inbetween. I have used
FORTRAN implementations that opened files that already
contained some records between the last formatted record
in the file and the (virtual) endfile record.

Assuming the file position after the OPEN statement is
executed is at the start of the file, then after the
WRITE statement is executed, the file should contain
one record. That record should start with the
sequence of characters "some text". The record might
contain additional characters depending on the
processor and external medium (see the third sentence
of paragraph 1 of Clause 9.2.2). Punched cards are
an obvious example. The second sentence of paragraph 4 of
Clause 9.3.4.3 assures that the record written is the last
record.

Bob Corbett

[stan]

robert....@oracle.com wrote:
<snip>

> Note 9.58 says "the exact meaning of the flush operation is not
> precisely defined."

So I'm not confused, I'm just not precisely defined? :)

[robert....@oracle.com]

On Mar 1, 9:44 am, stan <smo...@exis.net> wrote:

I do not know how precisely you are defined. I do know
that the relationship between a Fortran file and the
corresponding representation of that file on an external
medium is not precisely defined. People who expect the
intrinsic subroutine EXECUTE_COMMAND_LINE to have a
particular effect because of file operations performed
by a program will often be disappointed.

Bob Corbett

[stan]

My first thought was that the example was trying to peer at the inner
workings of the compiler. While interesting, I was sceptical of the
accuracy. Accurate or not, I stall can't reconcile all the results
after the flush or after the close.

This thread has been good for me because I've revisited some
expectations and I've discovered some really fuzzy thinking. Seems
like the advance yes|no seems to be attempting to be in the middle
between record and stream IO with some issues while trying to serve
two masters. Clearly, I need to be careful with IO until I get better
clarity. Time for some coffee and reading.

[Victor Eijkhout]

Terence <tbwr...@bigpond.net.au> wrote:

> For me, my F77 compilers won't accept POSITION and ADVANCE as valid
> keywords.

Same behaviour with PGI. Surprise....

Victor.
--
Victor Eijkhout -- eijkhout at tacc utexas edu