(j3.2006) VOLATILE or ASYNCHRONOUS function results ??

[Cohen Malcolm]

On Tue, 2017-01-10 at 14:16 +0000, Bill Long wrote:
> So, the value returned by the function as the result is disconnected
> from the value of the internal result variable?

No, the value returned by the function *IS* the value that the internal 
result variable had on execution of RETURN or END.  That's what the standard 
says.

>>   Otherwise, I have to
>> assume that it is the programmer?s fault if he/she  externally changes
>> the value in the memory location used by the result variable between
>> the end of the function execution and the point where the result value
>> is consumed (Note 15.40 in 17-007).

That memory location need not even exist!

Really, this is hardly different from TARGET; as I pointed out, we've had 
function result variables with the TARGET attribute for 25 years without 
anyone getting confused by this.

>> I?m happy to have the compiler just allow VOLATILE for the result
>> variable, and let the users shoot themselves in the foot if they are
>> so inclined.

I think that "for the result variable" could be deleted without changing the 
accuracy of those sentiments.

>The values of local variables in a BLOCK construct are not expected to 
>survive the end of the block.  Function results have to survive the end of 
>the function, since they are consumed by the expression where the function 
>reference appears.

No, the function result Does Not Survive.

A quote would seem to be in order here:

***BEGIN QUOTE
NOTE 15.40
The function result is similar to any other entity (variable or procedure 
pointer) local to a function subprogram.  Its existence begins when 
execution of the function is initiated and ends when execution of the 
function is terminated. However, because the final value of this entity is 
used subsequently in the evaluation of the expression that invoked the 
function, an implementation might defer releasing the storage occupied by 
that entity until after its value has been used in expression evaluation.
***END QUOTE

Consider a function whose result is INTEGER,TARGET::RESULT; this will, on 
most platforms, have the return value returned via a register, whereas the 
local entity with the TARGET attribute will actually occupy a memory 
location.  Thus perfectly illustrating the point.  That we don't have return 
registers big enough to hold arbitrary-sized arrays of arbitrary types (so 
those have to be returned via memory) is an implementation method, not 
language-defined.

ASIDE: The language used here was a lot clearer before we added functions 
returning procedure pointers (which I continue to believe was a mistake). 
We used to have clear terminology: the function result variable was the 
local entity, and the function result was the value returned.  Now we have 
the same words for both it can get quite confusing.  In fact when talking to 
colleagues I frequently use "result variable" to avoid the confusion (i.e. 
ignoring the existence of functions returning procedure pointers, which is 
pretty accurate considering the number of compilers that support those).

Cheers,
-- 
.............Malcolm Cohen, NAG Oxford/Tokyo.