Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

iso_varying_string

IanH
Honored Contributor II
1,235 Views

Is there an implementation of the iso_varying_string module from ISO 1539-2 that is recommended for use with Intel Fortran?

Thanks,

IanH

0 Kudos
4 Replies
Steven_L_Intel1
Employee
1,235 Views

ISO_VARYING_STRING was removed from the Fortran standard. The initial version, using pointers, was full of memory leaks. A revised version used allocatable components (rename to .f90) and is the best I can suggest, though I do not recommend it in general.

Fortran 2003 allows "deferred length" allocatable character values, but that's not yet in Intel Fortran.

0 Kudos
IanH
Honored Contributor II
1,235 Views

ISO_VARYING_STRING was removed from the Fortran standard. The initial version, using pointers, was full of memory leaks. A revised version used allocatable components (rename to .f90) and is the best I can suggest, though I do not recommend it in general.

Fortran 2003 allows "deferred length" allocatable character values, but that's not yet in Intel Fortran.


Thanks for the pointer. That looks like the implementation that I've been using.

In the absence of the F2003 deferred length character feature(*) and with the need to deal with unknown length character strings iso_varying_string is where I'm at.

There's been a change from IVF from 10.1.025 to 11.0.066 that "breaks" this particular implementation with reads at end of files. From what I can tell it's actually the iso_varying_string implementation that's technically responsible, but I'm not completely sure, so if those that know better can advise I'd appreciate it.

The attached program reads a text file (VaryingStringTest.txt) and writes each line to *. Under 10.1.025 it completes. Under 11.0.066 it dies (forrtl:severe) when it tries to read beyond the end of the file. The SIZE= specified on the read statement comes back with garbage when end of file is hit (as it legally can - because end of file means it's "undefined"), but I think the various get_* routines expect it to be zero (and previously, they got what they wanted).

I think all that needs to be changed is to whack in a reference to ios_fortran_env and change the loop termination IF's inside the get_* routines. Example from one of the routines below...

[cpp]    string = ''

    read_loop : do

       if(n_chars_remain <= 0) return

       n_chars_read = MIN(n_chars_remain, GET_BUFFER_LEN)

       if(PRESENT(iostat)) then
          read(unit, FMT='(A)', ADVANCE='NO', IOSTAT=iostat, SIZE=n_chars_read) buffer(:n_chars_read)
!  old
!          if(iostat < 0) exit read_loop
!          if(iostat > 0) return
! new (add use, intrinsic :: iso_fortran_env up above too)
           if(iostat > 0 .or. iostat == iostat_end) return
           if(iostat < 0) exit read_loop
       else
          read(unit, FMT='(A)', ADVANCE='NO', EOR=999, SIZE=n_chars_read) buffer(:n_chars_read)
       endif

       string = string//buffer(:n_chars_read)
       n_chars_remain = n_chars_remain - n_chars_read

    end do read_loop

999 continue

    string = string//buffer(:n_chars_read)
[/cpp]
Thanks,

IanH

(*) Please, please - the sooner this appears the better... The whole "fixed and blank padded" length character buffer thing is a painful nuisance to have to work around.


0 Kudos
Peter_Simon
Beginner
1,235 Views

Hi, Steve.

Could you please provide more detail on why you don't recommend the use of the improved iso_varying_string module? I'm looking at a project for which it would be very handy.

Thanks,
Peter
0 Kudos
Steven_L_Intel1
Employee
1,235 Views
It was never designed to be used in production code - more of an example, really. You can use it if you want. The version with allocatable components should work ok.
0 Kudos
Reply