Re: read(5,*) problem?

From: James Giles (jamesgiles_at_worldnet.att.net)
Date: 09/23/04 

Date: Thu, 23 Sep 2004 20:53:35 GMT

meek@skyway.usask.ca wrote:
> In a previous article, =?ISO-8859-1?Q?Jan_Vorbr=FCggen?=
> <jvorbrueggen-not@mediasec.de> wrote:
>>> You're right! at least in Alpha F90. That shakes my faith
>>> in fortran - but it is restored a bit in that WATCOM F77
>>> gives an error with read(iunit,*) unless strings are
>>> in quotes in the data file.
>>
>> As has been explained, the difference in handling unquoted strings
>> in list-directed input is one of the differences between F77 and F90
>> - so why shouldn't an F77 and and F90 compiler behave differently?
>> I can see no reason that your faith in Fortran should be shaken thereby.
>>
>> Jan
> In fact F90 didn't handle it well - it stopped at the '/'
> WATCOM F77 refused to handle it - which I agree with .
> It's ridiculous to have a "control" character in plain ascii.

What other "control" character can the standard expect to be
portable? ASCII? Then the control would be invisible, and
not portable to non-ASCII implementations (of which there
were quite a few when Fortran was faced with that decision).
Note that the meaning of slash as the terminator of input was
an F77 feature, not F90. Further, '/' was not then used for much
in Fortran programming environments outside of its use as a
divide operator, and division in the I/O list would be meaningless
(I presume that you also don't want it interpreted as a divide in I/O
either - my guess is that you think it's part of file pathe names).

What would *you* use as a *visible* and *portable* indicator
of the end of list directed input?

> Apart from the '/', having more than one string
> on a line without quotes is ambiguous - how do you know the
> spaces are not part of the string(s)

The spaces are also lot allowed in undelimited strings.
They are delimiters in all the other data types list-directed
I/O handles. So, the are delimiters for strings as well. 

-- 
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

Relevant Pages

  • Re: close(status=delete) on a missing file
    ... The same Fortran program will often still be able to open ... not capable of doing I/O on all the files present in a UNIX environment? ... no deficiencies and the other way is to make it so complicated ...
    (comp.lang.fortran)
  • Re: C String Interop
    ... "prefix=" too) ... Fortran shouldn't copy the things about C ... Fortran 2003 has deferred length strings ... no deficiencies and the other way is to make it so complicated ...
    (comp.lang.fortran)
  • Re: Most elegant way to read to allocatable array?
    ... That would be a lock that's needed whether the I/O used unit numbers ... locked longer during OPEN and CLOSE since you're modifying ... Fortran is even more underspecified. ... no deficiencies and the other way is to make it so complicated ...
    (comp.lang.fortran)
  • Re: printing in fortran
    ... Printf has a variable ... be aware of the fine print relating to I/O and C interop. ... If you open a file in Fortran, ...
    (comp.lang.fortran)
  • Re: a mergesort
    ... That would depend on how many records are processed, the quality of the I/O runtime, ... True for all lanuages but Fortran ... whereas comparison-based sorting takes time proportional to N.log N. ... 272343 calls to MergeLCP, 46442 skipped merges, 1320049 string comparisons ...
    (comp.lang.fortran)