This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC, Fortran, (pr66775)] Allocatable function result
- From: Andre Vehreschild <vehre at gmx dot de>
- To: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- Cc: GCC-Patches-ML <gcc-patches at gcc dot gnu dot org>,GCC-Fortran-ML <fortran at gcc dot gnu dot org>
- Date: Thu, 09 Jul 2015 20:59:08 +0200
- Subject: Re: [RFC, Fortran, (pr66775)] Allocatable function result
- Authentication-results: sourceware.org; auth=none
- References: <20150709122518 dot 08388506 at vepi2> <20150709175047 dot GA70209 at troutmask dot apl dot washington dot edu>
Hi Steve,
Thanks for your knowledge. Can you support your statement that an allocatable function has to return an allocated object by a part of the standard? I totally agree with you that this code is ill-designed, but IMO is it not the task of the compiler to address ill design. The compiler has to comply to the standard and the standard allows allocatable objects to be unallocated. So why has the result of a function be allocated always?
Regards,
Andre
Am 9. Juli 2015 19:50:47 MESZ, schrieb Steve Kargl <sgk@troutmask.apl.washington.edu>:
>On Thu, Jul 09, 2015 at 12:25:18PM +0200, Andre Vehreschild wrote:
>>
>> 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()
>> 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?
>
>Code is both valid and invalid. As you point out, it
>depends on the return value of more_input_available().
>Also, note, it is always invalid under -std=f95 as it
>is using automatic (re-)allocation of the LHS.
>
>> Unfortunately gfortran can not handle it currently.
>
>Whatever gfortran does is "correct", because the code is
>invalid in the more_input_available() = .false. case. It is
>the responsible of the programmer to ensure that getNext() has
>an allocated and assigned value before it returns. IHMO,
>I think that gfortran should not try to guess what the
>programmer might have intended.
>
>Yes, the compiled code may dereference a possibly invalid pointer.
>The compiled program should segfault, and the programmer should
>fix the Fortran code.
>
>function getNext()
> allocatable :: getNext
> if (more_input_available ())
> getNext = read_input()
> else
> allocate(getNext, source=some_error_code?)
> end if
>end function
>
>or
>
>function getNext()
> allocatable :: getNext
> allocate(getNext, source=some_error_code?)
> if (more_input_available ()) getNext = read_input()
>end function
--
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Mail: vehre@gmx.de * Tel.: +49 241 9291018