On Jul 11, 2015, at 4:58 AM, Dan Nagle danlna...@mac.com wrote:
The standard is written in standardese, not English.
While what you say is true, sorry, shall _is_ English:
used in laws, regulations, or directives to express what is mandatory
Le 10/07/2015 20:57, Steve Kargl a écrit :
On Fri, Jul 10, 2015 at 06:20:47PM +0200, Mikael Morin wrote:
I'm not completely convinced by the standard excerpts that have been
quoted about this topic, as they don't have any explicit mention of
allocatable variables/expressions.
I did not
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
Le 11/07/2015 12:36, Andre Vehreschild a écrit :
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
Hi,
module foo
contains
function bar(i)
integer, allocatable :: bar
integer, intent(in) :: i
if (i 0) bar = i
end function bar
end module foo
program test
use foo
integer j
j = bar( 3); print *, j
j = bar(-3); print *, j
Hi,
On Jul 11, 2015, at 04:36 , Andre Vehreschild ve...@gmx.de wrote:
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
On Sat, Jul 11, 2015 at 12:54:33PM +0200, Mikael Morin wrote:
Le 10/07/2015 20:57, Steve Kargl a ?crit :
On Fri, Jul 10, 2015 at 06:20:47PM +0200, Mikael Morin wrote:
I'm not completely convinced by the standard excerpts that have been
quoted about this topic, as they don't have any
Hi all,
this means that pr66775 is to be closed as resolved invalid, because the
current implementation is alright, but only the program to compile is garbage.
Ok, suits me.
- Andre
On Thu, 9 Jul 2015 12:41:31 -0700
Steve Kargl s...@troutmask.apl.washington.edu wrote:
On Thu, Jul 09, 2015 at
Yes, it should be closed. When I asked you to open it,
I thought the issue was a corner case in your patch.
--
steve
On Fri, Jul 10, 2015 at 11:44:32AM +0200, Andre Vehreschild wrote:
this means that pr66775 is to be closed as resolved invalid, because the
current implementation is
On Fri, Jul 10, 2015 at 06:20:47PM +0200, Mikael Morin wrote:
I'm not completely convinced by the standard excerpts that have been
quoted about this topic, as they don't have any explicit mention of
allocatable variables/expressions.
I did not quote 12.3.3 about characteristics of function
Hello all,
I'm not completely convinced by the standard excerpts that have been
quoted about this topic, as they don't have any explicit mention of
allocatable variables/expressions.
For what it's worth, in my opinion, the handling of allocatable that was
proposed by Andre makes sense to me.
Hi Mikael, hi all,
I only had the chance to check with ifort (different versions; including the
most recent one) and that compiler is consistent with gfortran as it is now,
I.e., the executable segfaults after the function has been called.
I am though curious what other compilers opinion on
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
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
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.
On Thu, Jul 09, 2015 at 08:59:08PM +0200, Andre Vehreschild wrote:
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
16 matches
Mail list logo
