Re: [RFC, Fortran, (pr66775)] Allocatable function result

[Andre Vehreschild <vehre@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 1755 bytes --]

Hi,

<snip>
>    "On completion of execution of the function, the value returned
>     is that of its function result. ... If the function result is
>     not a pointer, its value shall be defined by the function."

Now we can argue whether the "shall be defined" is to be interpreted as "has to
be" or as "might be". For me - being a non-native English speaker - that "shall"
is not an obligation but should be interpreted as "commonly the function result
is to be defined, but there can be exceptions". Now I am curious about how
native English speakers understand that standard statement.

My argument on returning an unallocated object is not to support programatical
errors, but rather for circumstances, where one tries to allocate a resource
and on failure nothing is returned. Think about a function like
try_to_acquire_resource(), when the resource could be reserved (like, for
example, a co-processor), then its (private) structure is returned
(implementing the OO concept of information hiding). Furthermore one could
think about using concepts like memory pools, where a memory fragment is
returned by a function as long as the capacity of the pool is no exhausted.
This of course is more difficult in Fortran as is lacks the ways of doing
C-style pointer arithmetic. This is just an example. So please don't nail me on
this one. I just wanted to give you my idea, why I think returning an
unallocated "object" should be legal for an allocatable function result. (Note,
the result is called allocatable, not allocated function result :-). Meaning,
that it can be allocated, but does not have to be.)

When someone has other compilers available the test program is attached.

Regards,
	Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

[-- Attachment #2: test_pr66775.f03 --]
[-- Type: application/octet-stream, Size: 1363 bytes --]

! { dg-do run }

module test_alloc_func_mod
  implicit none

  type t
    integer :: i = 5
  end type

contains

  type(t) function t_init()
    allocatable :: t_init
  end function

  type(t) function t_init2()
    allocatable :: t_init2
    allocate(t_init2)
  end function

  integer function i_init()
    allocatable :: i_init
  end function

  integer function i_init2()
    allocatable :: i_init2
    allocate(i_init2)
  end function

end module test_alloc_func_mod

program test_alloc_func
  use test_alloc_func_mod

  type(t), allocatable :: temp
  type(t), allocatable :: vec(:)
  integer, allocatable :: i

  temp = t_init()
  if (allocated (temp)) call abort()

  temp = t_init2()
  if (.not. allocated (temp)) call abort()
  if (temp%i /= 5) call abort()
  deallocate(temp)

! The next two lines create a memory corruption/segfault, because the result
! of i_init() is not allocated but dereferenced.
!  i = i_init()
!  if (allocated (i)) call abort()

  i = i_init2()
  if (.not. allocated(i)) call abort()
  deallocate(i)

  allocate (vec(5))
  vec = t_init2()
  if (.not. allocated(vec)) call abort()
  if (any(vec%i /= [5,5,5,5,5])) call abort()
  deallocate (vec)

  allocate (vec(5))
  vec(:) = t_init2() ! Note the colon op.
  if (.not. allocated(vec)) call abort()
  if (any(vec%i /= [5,5,5,5,5])) call abort()
  deallocate (vec)

end program