Misguided warning 1179?

FORTRAN 95 does not allow user-defined types to contain allocatable components, and the workaround is to allow allocation via pointer instead. I have happily been allocating and deallocating derived type components for a while now, but only this morning did I get around to writing code that tested the allocated status of one of them.

The following code provokes (from FTN95 v5.40) warning 1179: - WORKAROUND is not ALLOCATABLE yet is used in an ALLOCATED test.

I think this is wrong, since it is not workaround that is being used in the test, but its allocatable component. Note that the corresponding allocate statement is not flagged as erroneous.

I appreciate its only a warning, and thus non-fatal, but I'd be decidedly happier in ignoring it if other folks who have been doing this new-fangled FTN95 stuff longer than me were in agreement that this warning should not be issued in the first place.

Comments?

<edited immediately post-posting> I hadn't actually tried to run the compiled code when I posted. When I do, I get an access violation on the if (allocated) ... statement.

So clearly there's more to this than meets the eye - mine, anyway. I was wondering whether I have to nullify the pointer before I can test its allocated status? But it can't be that simple - if the component is already allocated, say elsewhere in a module like in my real code, there is no reason why I should not be able to test its allocated status.

Thoughts?

Andy

    program hello_kate

    type contains_pointer_for_allocation_purposes
      integer, pointer :: pseudo_allocatable (:)
    end type contains_pointer_for_allocation_purposes

    type (contains_pointer_for_allocation_purposes) workaround

    if (allocated (workaround% pseudo_allocatable)) deallocate (workaround% pseudo_allocatable)

    allocate (workaround% pseudo_allocatable (10))

    stop
    end program hello_kate

I think that you are right. This is a false warning.

Please have a look at my edit while you were replying 😃

My understanding is that you should nullify the pointer....

program hello_kate

type contains_pointer_for_allocation_purposes
integer, pointer :: pseudo_allocatable (:) => null()
end type contains_pointer_for_allocation_purposes

type (contains_pointer_for_allocation_purposes) workaround

if (allocated (workaround% pseudo_allocatable)) then
  deallocate (workaround% pseudo_allocatable)
endif  

allocate (workaround% pseudo_allocatable (10))

stop
end program hello_kate

Yes, I had come to the same conclusion, but via the nullify statement - even though Metcalf & Reid says nullification allows legitimate testing for disassociation rather than unallocatedness - all as it were.

Use of nullify seems to work, but I don't know why, because syntactically it treats the component as a pointer to an array rather than as an array of pointers.

I can't find any reference to NULL () in M&R 'FORTRAN 90 explained' - was it introduced in the transition to FORTRAN 95? I found it in the FTN95 help file, but there it is referred to as an alternative to nullify, still with the purpose of legitimizing testing for disassociation rather than unallocatedness.

Also, I hadn't realised it was possible to assign initial values to components within a type definition - that's pretty wizardly. And the real beauty is it correctly handles the component as an array of pointers.

I love FORTRAN 95.

Yes I think NULL() is in 95 and not in 90.

I didn't think allocated() worked for pointers - I use associated() when dealing with pointers (along with initialisation in the type definition using null()).

My understanding is use associated() for pointers, allocated() for allocatables. Of course being pointers you have to be very careful about nulling them after use if you're going to ever use them again - I always work on the rule that all pointers are initialised to null(), are tested using allocated, and are set to null whenever they are deallocated. Seems to work okay.

Quoted from acw I didn't think allocated() worked for pointers - I use associated() when dealing with pointers (along with initialisation in the type definition using null()).

My understanding is use associated() for pointers, allocated() for allocatables. Of course being pointers you have to be very careful about nulling them after use if you're going to ever use them again - I always work on the rule that all pointers are initialised to null(), are tested using allocated, and are set to null whenever they are deallocated. Seems to work okay.

I presume you meant 'are tested using associated' in the second para, based on what you said in the first?

I understand what you are saying and my reasoning would have been the same - except that given that this particular flavour of pointer is there only to be able to work around the inability to have ALLOCATABLE components in user-defined types, and therefore has to be ALLOCATEd, it seems perverse not to be able to test their ALLOCATED status ... or to put it another way, if:

allocate (x(n))

is valid code, so should be:

if (allocated (x(n)))

Testing for ASSOCIATEDness might return .TRUE. or .FALSE. - it depends what's been done since the ALLOCATE - so that can't be the right test?

Andy