Prev: gui fortran
Next: removing /save fortran compiler option
From: fj on 4 Jul 2010 06:57
On 4 juil, 12:52, "Philipp E. Weidmann" <philipp.weidm...(a)gmx.de>
wrote:
> fj wrote:
> > On 4 juil, 11:17, "Philipp E. Weidmann"<philipp.weidm...(a)gmx.de>
> > wrote:
> >> I'm in the process of modifying a program that was previously compiled
> >> with ifortran so that it will work with gfortran as well (Windows is my
> >> testbed), and I have discovered that files written by the ifort-compiled
> >> version will not work with the gfortran-compiled version.
>
> >> There are two apparent reasons for this:
>
> >> 1. The program compiled with ifort terminates lines it writes to a file
> >> with CRLF, while the gfortran version uses LF only.
>
> > A source file is NEVER produced by a compiler like ifort or gfortran
> > but only by a text editor !
> >...
>
> Please re-read my problem statement:
>
> "*The program compiled with ifort* terminates lines *it* writes to a
> file with CRLF, while the gfortran version uses LF only."
>
> I wasn't talking about compilers but about programs produced with
> differend compilers.
>
> --
> -- Philipp Emanuel Weidmann

Sorry : I misread your sentence :-(
From: Richard Maine on 4 Jul 2010 12:24
Tobias Burnus <burnus(a)net-b.de> wrote:

> As list-directed *input* only reads until the line break,

That would be a violation of the standard. I seriously doubt that either
compiler violates the standard in that way. List-directed input reads as
many lines as needed to find enough data fields.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: Tobias Burnus on 4 Jul 2010 14:13
Richard Maine wrote:
> Tobias Burnus wrote:
>
>> As list-directed *input* only reads until the line break,
>
> That would be a violation of the standard.

Wow - something in I/O which actually violates the standard. So far, I
had the impression that (almost) anything goes - though only few choices
are possible for sensible implementations.

> I seriously doubt that either
> compiler violates the standard in that way. List-directed input reads as
> many lines as needed to find enough data fields.

Thanks for the correction!

I must have mixed this up with something else Fortran I/O related. (And
I remember problems with non-Fortran postprocessing such as with gnuplot
- which is completely outside of the Fortran standard.)

I probably should write less about Fortran I/O, which is an area where I
do not know much - though I keep learning. (For instance that Fortran
(but also C99's strtod) accept not only "NaN" but also
"NaN(alphanumeric)" or that F2008 now allows all logical kinds in I/O
statements.)

Tobias
From: Dave Allured on 4 Jul 2010 14:26
Philipp E. Weidmann wrote:
>
> I'm in the process of modifying a program that was previously compiled
> with ifortran so that it will work with gfortran as well (Windows is my
> testbed), and I have discovered that files written by the ifort-compiled
> version will not work with the gfortran-compiled version.
>
> There are two apparent reasons for this:
>
> 1. The program compiled with ifort terminates lines it writes to a file
> with CRLF, while the gfortran version uses LF only.

The same issue comes up perpetually when transporting text files between
platforms. I make it the responsibility of my more general purpose
readers to accomodate the common variations. To put it bluntly, I do
not know why two compilers produce different line terminators, I don't
want to know, but I can write defensive reader code that should be able
to accept either.

If both compilers can read files with either terminator, as Tobias
mentioned, then the following should not be needed for your specific
case.

subroutine read_line (infile, line, ios) ! untested
implicit none
integer, intent(in ) :: infile
character(*) intent(in ) :: line ! oversize length
integer, intent(out) :: ios
character, parameter :: cr = achar(13)
integer j
read (infile, '(a)', iostat=ios) line
if (ios /= 0) return
j = len_trim (line)
if (j > 0) then
if (line(j:j) == cr) line(j:j) = ' '
end if
end subroutine read_line

Main program...

call read_line (infile, line, ios)
if (ios /= 0) handle EOF or error...
read (line, '(...)') a, b, c ...

Side note: I do not know whether the protective "if (j > 0)" is
necessary. Is the evaluation of "line(j:j)" standard conformant when j
equals 0?

> 2. The string written by the command
>
> WRITE(file_unit,*) real8_value (where real8_value = 0)
>
> is "0.000000000000000E+000" when using ifort but "0.0000000000000000"
> when using gfortran (I'm not sure this actually causes any problems,
> though).
>
> Is there any way around these issues so that files written by a ifort
> compiled program will be understood by a gfortran version of the same
> program, and vice versa?

As others noted, both zero forms with and without the suffix should read
back correctly with fortran numeric input. Therefore, no change should
be needed for the purpose of a general fortran reader, unless you also
want the files to "look" identical.

--Dave
From: Richard Maine on 4 Jul 2010 14:53
Dave Allured <nospom(a)nospom.com> wrote:
....
> j = len_trim (line)
> if (j > 0) then
> if (line(j:j) == cr) line(j:j) = ' '
> end if
> end subroutine read_line
....
> Side note: I do not know whether the protective "if (j > 0)" is
> necessary. Is the evaluation of "line(j:j)" standard conformant when j
> equals 0?

Yes, the protection is needed because line(j:j) is nonconforming when j
is 0. From f2003:

"both the starting and the ending point shall be within the range 1,
2, ... n, unless the starting point exceeds the ending point..."

One might be able to come up with a "neat hack" to avoid the explicit
test, but the test is probably a lot clearer (and you are less likely to
mess it up, as I almost did in trying to show one such hack, which
wouldn't have worked because I got a piece backwards).

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: gui fortran
Next: removing /save fortran compiler option