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

[Andre Vehreschild <vehre at gmx dot de>]

Hi all,

I need your help on how to interpret the standard(s) or how to implement
handling an allocatable function's result, when that result is not allocated by
the function. Imagine the simple (albeit artificial) case:

integer function read_input()
  ! Do whatever is needed to read an int.
  read_input = ...
end function

integer function getNext()
  allocatable :: getNext
  if (more_input_available ()) getNext = read_input()
end function

where the function getNext () returns an (automatically) allocated result when
more_input_available() returns .true.. Otherwise getNext () returns an
unallocated object, i.e., the result's allocation status is .false.. I don't
want to argue about this design's quality (considering it poor myself). I
suppose that this code is legal, right?

Unfortunately gfortran can not handle it currently. The issue here is shown in
the pseudo code of:

integer, allocatable :: res
res = getNext ()

The pseudo code does this:

 	integer(kind=4) * D.3425;

        if (res != 0B) goto L.6;
        res = (integer(kind=4) *) __builtin_malloc (4);
        L.6:;
        D.3425 = getnext ();
        *res = *D.3425; // Oooops! D.3425 is NULL, when more_input_available ()
		        // is .false.

That is there is a classic null-pointer dereference.

I am curious why the memory allocated (or not) by the function is not reused for
the allocatable object on the lhs? I propose to generally handle an assignment
of a scalar allocatable(!) function result to a scalar allocatable(!) variable
like this (shortened a bit for brevity):

 	TYPE * res, D.3415, D.3417;

        D.3415 = get_next ();
        // Swap new result and old contents of res.
        D.3417 = D.3415;
        D.3415 = res;
        res = D.3417;
        // Deallocate old content of res to prevent memory leaks.
        if (D.3415 != 0B)  __builtin_free (D.3415);

Note there is no initial malloc of res! Would this do any harm, besides
preventing memory loss, saving an allocation and be cleaner to read on the
pseudo code side. Does it violate the standard somehow? Any ideas on
alternatives to prevent the null-pointer dereference in the initial code?

Suggestions, issues, objections???

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