Allocation of variable length character arrays

Why does the text array fail to be allocated in the following code?:

ichar_len  = 32 
iarray_len = 1000
call text_allocatable(ichar_len,iarray_len)
.
.
.

subroutine text_allocatable(ichar_len,iarray_len)

character (len=ichar_len), allocatable, dimension(:) :: text_array
integer   (kind=3), allocatable, dimension(:) :: isort_list
print *,ichar_len,iarray_len
allocate (text_array(iarray_len), stat=istat)
allocate (isort_list(iarray_len),    stat=jstat)

print *,'allocation status',istat,jstat
      
if(istat .eq. 0)then
  deallocate (text_array)
endif
if(jstat .eq. 0)then
  deallocate (isort_list)
endif
     
end

Using (len=32) or parameter(ichar_len=32) instead of passing through the call statement works.

The Fortran 95 Handbook suggests that this will work. And assuming you have a copy, Section 6.5.1, Rules & restrictions item 10.

Regards

Ian

try using nullify(text_array) instead of deallocate I think I had a similar problem and it worked for me!

I should have said that the status values are: istat = 2 jstat = 0

Which means that the text_array has not been allocated, but the integer one has.

If I did not test the status, then an error would occur when deallocating.

Ian

Before checking this out in detail I just want to make sure that you are not using version 5.20 of FTN95 which has a known regression concerning some uses of ALLOCATE.

Paul, I'm using version 5.20.1 - see listing. salflibc.dll dated 02/03/2008 time 01:32

Regards

Ian

Silverfrost FTN95/WIN32 Ver 5.20.1 allocate.F95 Tue Apr 8 18:40:58 2008

Compiler Options in Effect: COLOUR DELETE_OBJ_ON_ERROR LINK LIST MINIMISE_REBUILD NO_QUIT NON_STANDARD SINGLE_THREADED

0001 program allocate 0002 ichar_len = 32 0003 iarray_len = 1000 0004 call text_allocatable(ichar_len,iarray_len) 0005 end 0006 0007 0008 subroutine text_allocatable(ichar_len,iarray_len) 0009 0010 character (len=ichar_len), allocatable, dimension(:) :: text_array 0011 integer (kind=3), allocatable, dimension(:) :: isort_list COMMENT - Specifying the kind of the type INTEGER with the constant '3' is non-portable - 'SELECTED_INT_KIND(9)' would be better 0012 print *,ichar_len,iarray_len 0013 allocate (text_array(iarray_len), stat=istat) 0014 allocate (isort_list(iarray_len), stat=jstat) 0015 0016 print *,'allocation status',istat,jstat 0017 0018 if(istat .eq. 0)then 0019 deallocate (text_array) 0020 endif 0021 if(jstat .eq. 0)then 0022 deallocate (isort_list) 0023 endif 0024 0025 end

OK, this looks like a bug we have not seen before. We will aim to fix this soon but the fix probably wont be available until the next major release.

This bug has now been fixed.

Thanks

Ian

PS, when will the outside world see this fix?

In the next release of FTN95 which would normally be 6 to 12 months from now.

Paul,

I have a similar problem in 5.21 (also appeared and reported in 5.20 & 5.20.1) where an array allocated within a subprogram is going haywire. It works in previous versions so I haven't been able to upgrade. I've tried to trim it down to a reportable size with no success so far (it's a big program).

Is there any chance I can try out the fixed version now to see if my problem has gone away ? It'll save us all a pile of time if it has.

Thanks, Alan

The bug is very specific to allocating memory for a character array where the character length of an element is supplied as a variable argument.

If you have exactly this situation then it will be necessary to use a work-around or to apply to Silverfrost for an intermediate build.

If you have a different problem that cannot be isolated then you can apply to Silverforst to send a zip archive of all the code for forwarding to me.

My problem is with a pointer-based integer array within an ADT where the length of the array is passed as an argument. Sounds like it's not the same problem but a bit too similar for comfort.

There is more info at my earlier report on the same problem at https://forums.silverfrost.com/Forum/Topic/780. I'd appreciate some comment on this in case it's in some way related or rings a few bells. It is going to quite a lot of work to slim it down so any ideas would be gratefully received. Either that or stick to using v4.91.

How does one apply for an intermediate build - is it not worth trying it out ?.

Alan

I have been able to cut this down. The demo program can be downloaded from: http://www.wsanoise.com/testsite/download/FTN95AllocateBug.zip

It's a full solution with various watches and a breakpoint set - the comments in the code describe the problem but basically an allocate seems to corrupt memory around it but it's highly dependent on the surrounding code. It only happens on versions 5.20 and above (incl 5.21) on XP and Vista on VS2008.

Cheers, Alan

I have downloaded your zip archive and the 'bug' still seems to be there. Also, strangely, when I run your code through the debugger, Visual Studio gives me a serious error warning (but continues running).

We will investigate the 'bug' as soon as we can.

This bug has now been fixed for the next release.

When will that appear?

Greetings, Katrijn

It is not long since the last release so the next release could be in approximately 6 to 9 months time.