CHARACTER(LEN=:),DIMENSION(:),ALLOCATABLE :: a ?

[Ayyy LMAO]

Hello everyone,
I'd like to dinamically set both the extent and length of a one dimensional array of characters.
The following code, however, is not working as intended and returns, for any position in the array, just the last value entered. Here is the code:

PROGRAM hello
IMPLICIT NONE

CHARACTER(LEN=:),DIMENSION(:),ALLOCATABLE :: array_lineas
INTEGER :: largo , cant_lineas , i
WRITE(*,*) ' Escriba un numero para el largo de cada linea'
READ(*,*) largo

WRITE(*,*) ' Escriba la cantidad de lineas'
READ(*,*) cant_lineas

ALLOCATE(CHARACTER(LEN=largo) :: array_lineas(cant_lineas))

WRITE(*,*) 'Escriba el array'
READ(*,*) (array_lineas(i),i=1,cant_lineas)

WRITE(*,*) 'Array guardado: '
DO i=1,cant_lineas
WRITE(*,*) array_lineas(i)
ENDDO

READ(*,*)

END PROGRAM

So my question is, is the above syntax for the allocation incorrect, or is that feature not supported by the compiler ? I'm using gfortran 5.2.0 on windows 7
Thank you

Francisco.

[Richard Maine]

Code looks fine to me. Intel Fortran 16.0 seems to agree and works as
expected on this Mac.

Compiles, but just output blanks in the test I ran with gFortran 4.9.2
on the Mac, though I'm aware that's not a current version. Looks like a
gFortran bug to me. I've generally been dissapointed that allocatable
character length has been so slow to get implemented in many compilers.

--
Richard Maine
email: last name at domain . net
dimnain: summer-triangle

[paul.rich...@gmail.com]

This persists in gfortran-6.0.0. I have posted it on Bugzilla as PR68216.

It is the read statement that is causing the segfault as assignment of strings to array_lineas demonstrates. I'll take a look at the problem today. At first sight, the compiled code seems to be trying to do the right thing.

Paul

[Blokbuster]

I don't believe that allocatable arrays of allocatable-length characters work in gfortran at all, e.g. the following code doesn't behave as expected (although it compiles without complaint):

program testdefchar
implicit none
character(:), allocatable :: test(:)

allocate(character(3) :: test(2))
test(1) = 'abc'
test(2) = 'def'
write(*,*) test(1), test(2)

test = ['aa','bb','cc']
write(*,*) test(1), test(2), test(3)

end program testdefchar

gives:

defdef
cccccc
(gfortran 5.2)

[paul.rich...@gmail.com]

Yes - I get the same on 6.0.0. OK, the problem runs deeper than I thought. There are a number of problem reports in respect of deferred length, allocatable arrays.

I'll see what I can do.

Paul

[Anton Shterenlikht]

Seems to be a bug in gfortran.
With ifort 15 and Cray 8.3.7,
I get all strings out correctly, e.g.:

$ ./a.out

Escriba un numero para el largo de cada linea

11

Escriba la cantidad de lineas

4
Escriba el array
a;sdlkjf;asdkjfa;sdkf
10238947148971293487
j9j9j9j9j9j9j9j9j
98nf98n2fma34sd
Array guardado:
a;sdlkjf;as
10238947148
j9j9j9j9j9j
98nf98n2fma


$ ./a.out

Escriba un numero para el largo de cada linea

11

Escriba la cantidad de lineas

5
Escriba el array
a;sdlkfja;sdkjfa;skfasd
1034891283471023948710324
8f88s8s8g9d8s8s8s8s
4mn9078asd413f1dfy5
0897sae45mnof493
Array guardado:
a;sdlkfja;s
10348912834
8f88s8s8g9d
4mn9078asd4
0897sae45mn

Anton

[Ayyy LMAO]

Well, I guess I'll have to do with fixed length strings for now (which for my application is completely fine), but it's good to know paid compilers support the feature, big thanks to all who tested the code.

[Anton Shterenlikht]

Maybe you can workaround with derived types,
something like this:

type t
character(:), allocatable :: c
end type t

integer, parameter :: arrlen=3
type(t),allocatable :: arr(:)

allocate( arr( arrlen ) )

arr(1)%c = "mumu"
arr(2)%c = "-onpfo4ea2"
arr(3)%c = "-09npqoef"

do i=1, arrlen
write (*,'(a)') arr(i)%c
end do

end

which with gfortran6 gives:

$ ./a.out
mumu
-onpfo4ea2
-09npqoef

Anton

[paul.rich...@gmail.com]

I have made a lot of progress today in isolating the causes of the bugs that make gfortran fail to produce a good executable for the original code. I have "Blockbuster"'s testcase working. The allocation was not returning the string length to the array descriptor such that the calls to the IO library did not get the correct value. The original testcase is still suffering from a problem with array references (which I thought was a problem with the IO). I should have it cracked tomorrow :-)

Paul

[Blokbuster]

Paul,

thanks for taking the time to look at this - this feature working would help me a lot!