Silverfrost Forums

Welcome to our forums

transfer function error/bug.

27 Jun 2010 11:18 #6565

Hello everyone,

I am creating some 'generic' subroutines using transfer to move data between actual data type and an array of 1 byte characters.

I found that the use of the transfer function highlighted with a comment (***Error) in the following code doesn't work when I compile in CHECKMATE WIN32 mode, but works fine in DEBUG WIN32 mode.

I get a run time error that the character array is not defined when I run this in Plato. (In the FTN95 Express GUI it just crashes).

Is this a bug or am I missing something? Any help or information would be appreciated. I'm using Version 5.4 of FTN95 (as 5.5 doesn't seem to be available for download yet).

module increments

   type Composite
      integer :: i
      real :: r
   end type Composite

contains

   subroutine incrementComposite(data)
      character(len=1),intent(inout) :: data(:)
      type(Composite) :: b
      b = transfer(data, b)
      b%r = b%r + 1.0
      b%i = b%i + 1
      print *, b%r, b%i
      data = transfer(b,data) ! ***Error here when in CHECKMATE mode
   end subroutine incrementComposite
   
   subroutine incrementTenTimes(func, data)
      character(len=1) :: data(:)
      interface
         subroutine func(data)
            character(len=1),intent(inout) :: data(:)
         end subroutine func
      end interface
      integer :: i
      do i=1,10
         call func(data)
      end do
   end subroutine incrementTenTimes

end module increments

program anon
   use increments
   type(Composite) :: b
   character(len=1), allocatable :: data(:)
   integer :: lengthData
   
   b%i = 0
   b%r = 0.0
   lengthData = size(transfer(b,data))
   allocate(data(lengthData))
   data = transfer(b,data)
   call incrementTenTimes(incrementComposite,data)
   b = transfer(data,b)
   deallocate(data)
   
   pause
end program anon
28 Jun 2010 10:09 #6580

Personal Edition 5.5 has been available for some time. Supported customers have had version 5.50 available from the release date.


-- Admin Silverfrost Limited
29 Jun 2010 6:48 #6584

The latest FTN95 Express download only includes 5.4. (This is what I have).

I see from the KB you can install FTN95 Personal (to get 5.5) and then install only the IDE part of FTN95 Express. I will try that.

Will this fix the problem though?

12 Jul 2010 3:40 #6604

I am not sure what is going on here. The effect is apparent in version 5.5. I will aim to investigate when I can find time.

21 Jul 2010 2:58 #6662

Although this is technically a bug it is one of those that does not warrant a fix.

/checkmate (i.e. /full_undef) includes a check for undefined character values and these appear as Z'80'. FTN95 has applied this check before calling the transfer function and has found such a value.

The check is probably not warranted in this case but it does not seem reasonable to avoid this very special situation in the compiler code.

As a user you should use no more than /undef and not /full_undef in this local context. i.e. do not test for undefined character variables within this particular routine.

28 Jul 2010 11:17 #6704

Thanks Paul.

Sorry, I have not visited for a while and missed your posts but I'm very interested in your view.

Are you saying that you can't assume that you won't get hex 80 bytes in your data so /CHECKMATE will sometimes return false positives? Does this apply to all variable types or just character arrays?

If so its just a limitation of the method and can't be fixed without a total re-write of the compiler.

I was able to get the code above working by using an integer array as the 'buffer' instead of a character array. However, I realised the concept was not really a good idea (too difficult to understand) and I have abandoned it now.

David.

29 Jul 2010 6:15 #6705

In fact I ended up by fixing this 'bug' in the compiler although is is a very special case.

The reality is that the compiler has to use some value to represent the undefined state for each of the standard Fortran types. This means that, in general use, there will be very rare 'random' events that cause the undefined checking to hit this undefined state. It is not surprising therefore that the transfer function is not really a candidate for applying this check.

Anyway, as I say, I have fixed this for the next release so everything should be OK in the present case.

Please login to reply.