Clive Page wrote:
>I had not appreciated the substantial differences between formatted and 
>unformatted stream I/O, and had only looked properly at the sections of 
>the Standard describing the former.

Right.

Of course these are meant to interoperate with the different kinds of C
files, as I mentioned.  In strict C (that is, by the C standard), binary
and text files behave quite differently.  On Unix these are essentially
identical.  But on other operating systems (C has existed on IBM MVS, DEC
VMS, not to mention uSoft Windows) these are either slightly different or
wildly different.

Unix C programmers often don't appreciate this - as they used to say
"All the world's a VAX" (meaning VAX Unix).

>However  there does not seem to be any corresponding statement in 
>9.5.3.4.2 describing formatted data transfer.  To me this looks like an 
>unfortunate omission from the Standard.

I remembered where one part of this was - in 10.6.3 and 10.7.2.
This covers the situation where a complete record is transferred
(the normal situation), and is quite clear (even if it might not
be where you were expecting it!).

For non-advancing i/o, I think the language is a little harder to find and
understand.  Maybe some of 10.7.1 helps (then again, maybe not since it
talks about transmission of characters to/from the record instead of the
file -- some of the terminlogy could do with updating here).  Actually,
I think the difficulty here is pretty much unrelated to stream i/o and
is all involved in non-advancing i/o.  I'd hesitate to say that it was
wrong or omitted though, even if I think it warrants improved wording.
(Saying "I can't nail it down" is not equivalent to "It is not fixed down".)

>Actually, I still don't quite see why the restriction is needed: what 
>harm can come from being able to re-write a section of a file starting 
>at any arbitrary byte-offset, since one can do this with an unformatted 
>file?  I suppose it must be something to do with the penchant that some 
>systems have for inserting arbitrary CR and/or LF characters in 
>formatted output, which would make the resulting character-count hard to 
>determine.

It's worse than that, though that is one aspect.  Consider what happens
to a file with variable-length records with embedded record counts (not
that uncommon a file format outside of Unix; VMS and MVS both have these,
for example).  If you write to it thinking it is a Unix file, you are
likely to clobber a record count and end up with complete gibberish if not
an invalid file.

Anyway, can I refer you to a very important section of the
Fortran standard: "1.1 Scope".  I quote

  "The purpose of [the Fortran standard] is to promote portability,
   reliability, maintainability, and efficient execution of Fortran
   programs for use on a variety of computing systems."

Relaxing the restriction you mention would promote non-portability,
unreliability, maintenance difficulty ... and all without improving
execution efficiency.  So it really goes against the whole point of
having a standard in the first place, which is so that people can
write programs and expect to have some chance of them working,
and continuing to work later.

>I can't help feeling that the description of stream I/O in the F2003 
>Standard is somewhat less than clear.  I think the basic mistake is for 
>it to be interspersed with the complexities of record-handling.

Well, a C "text stream" or Fortran "formatted stream" is in fact a record
file.  If you read the C standard that is in fact how they are described,
though it uses the term "lines" instead of "records".  And on many C
implementations, in particular the ones I mentioned before on MVS VMS et
al, C reads (and can write) the native record files perfectly fine.

So I disagree that the formatted i/o stuff (around 30 pages) should be
duplicated - the differences between the two versions would, I think,
be less than 2 pages worth.  That argues very strongly that we should
say it once, not twice.

> The whole point of stream I/O, I thought, was that for the first time it 
>frees the Fortran programmer from the shackles of record-based I/O.

I'm not sure which shackle you mean.

One that it does free you from is the fixed record length of a
sequential file.

It doesn't free you from being able to do
   WRITE(stream,*) "The value of X is",X
and have it work (and do the obvious thing).  Suggesting that this
shouldn't work would be akin to suggesting to a C programmer that "printf"
and friends are entirely wrong-headed and should be avoided as "shackles",
and is unlikely to receive a favourable reaction.

>If only IBM had been using punched tape instead of cards at the time 
>Fortran was invented, maybe this whole elaborate edifice would never 
>have been constructed?

Au contraire.  Formatted i/o is fundamentally about communicating with
people.  Not many people prefer to read their book or newspaper on a
kilometre-long strip of paper.

Even unformatted i/o was based on records (magtapes worked that way).
Losing the record structure doesn't actually change very much except
what you can do (no record structure = more restrictions on what the
programmer can do), which in turn enables different compiler optimisations
(for a disc file, don't bother to write the record lengths).

So I'd say that in every sense except the record length, a stream file puts
MORE shackles on the programmer, not fewer.

Cheers,
-- 
...........................Malcolm Cohen, Nihon NAG, Tokyo, Japan.
                           ([log in to unmask])