----------
> Dan Nagle wrote:
> >
> > Hello,
> >
> > Richard Maine wrote:
> > >
> > <snip PROTECTED discussion>
> > >
> > >  > 5.  I hope the suggestion for stream IO isn't lost in the
> > >  >     PROTECTED discussion.  This is certainly an F2K + 1 issue,
> > >  >     it seems 'too big' for a last-minute inclusion.
> > >
> > >   1. No formatted stream I/O.  While perhaps nice, this adds many
> > >      complications, and is not the most critical need.  No, I'm not
> > >      negotiable on this.  I might possibly agree to a proposal that
> > >      included formatted stream I/O, but I do *NOT* have time to
> > >      write one (not if its to do a good job).
> >
> > Agreed.  The programmer can always read into a character string,
> > and roll-yer-own formatting.
>
> And the non advancing I/O of Fortran 95 is already a good step.

> > >   2. No random positioning.  This would certainly be a desirable
> > >      feature, but it raises questions that might start enough debate
> > >      to derail approval.  (Namely - do you position by byte-number,
> > >      word-number, system-dependent units, or possibly only to points
> > >      returned by some form of inquiry?)  I'd rather go without it at
> > >      first, and consider it as a possible later add-on.  Plus, I
> > >      haven't considered it carefully enough yet myself to be sure of
> > >      my preferences.

Any random access should be on a byte basis, not on a unit basis.

As an alternative, on a unit that is the size of a single variable specified
in the I/O list.  This would allow single-character access, integer word access,
or whatever.

Don't want processor-defined units.  They aren't particularly portable,
and in any case, wouldn't allow single-byte access.

> > Agreed.  If you want to choose a unit, how 'bout the unit used
> > by the IOLENGTH specifier?  Presumably, that's a unit the processor
> > is comfortable with (i.e., no byte addresses on word addressable
> > processors, etc.).
> >
>
> In fact, this feature could be added very easily:
>
> 1- By adding a POS= specifier in READ and WRITE statements such
>  as: READ(1,POS=position)input_list where position is in a unit that
>  remain to be determined.
>
> 2- By adding a CURRPOS= option in INQUIRE to query about the current
> position of the file pointer. Following an OPEN, the position returned
> by CURRPOS is 1, if POSITION is anything other than APPEND, and the
> size of the file + 1 if POSITION = 'APPEND'.
>
> The only obscure point is the choice of the unit used to address the
> file. The unit used by IOLENGTH is an acceptable choice.

Definitely NOT.  See above.

> > >   3. Syntax basically identical to unformatted sequential I/O (minus
> things
> > >      like backspace and anything else that seems incompatable).
> >
> > Agreed.
>
> I consider however that the "binary" WRITE should only overwrite the
> portion of the file corresponding to the length of the output list,

This is how random access normally works.

> in the contrary of an unformatted sequential WRITE. The remaining of the
> file should remain unchanged. If the user wants to truncate the rest of
> the file, ENDFILE should be used instead. REWIND should also be
> allowable.

> Regards,
> Jean Vezina




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%