[fpc-devel] Managed Types, Undefined Bhaviour

[Stefan Glienke]

Am 29.06.2018 um 20:10 schrieb Jonas Maebe:

> That does not make any sense to me from a language design point of 
> view. Either the language guarantees that managed function results are 
> initialised to empty, or it does not. The fact that these are the same 
> or different temps, or if there are no temps at all, should not matter 
> in the least. Otherwise you are defining the behaviour of the language 
> in terms of the quality of the compiler's alias analysis (since if it 
> can prove that it does not need a temp, the function result may not be 
> empty on entry).
The issue is that reusing a temp variable for a second call while it 
still has some already allocated array in it causes the code to behave 
differently even if you declare {$mode delphi}. In Delphi it is clear 
that if a temp variable is being used it was initialized to be empty in 
the prologue. The only case (I know of) where a call with a non 
initialized temp variable happens is when the statement is called in a 
loop and it does in no way happen that one statement affects the 
behavior of a different statement in the same routine.

It is true that function results of managed types are not initialized 
but passed as var parameter. However it should be ensured that they are 
in a defined state. If the LHS is being passed you know its state. If a 
temp variable is being passed it should be initialized (like Delphi 
does). Reusing temp variables holding intermediate values introduces 
hidden side effects.

If I am not mistaken (this is from my observarion and might not be 100% 
accurate) usually the rule in Delphi (possibly similar in FPC) when it 
allows to directly pass the LHS as hidden result parameter is when it is 
a local variable. Now with the dynamic array we have the case that since 
the content of the temp variable was being copied it then when being 
reused has a ref count of 1 causing SetLength to just realloc the memory 
and possibly keep any existing content of the array copying it then on 
to the LHS of a second statement as shown in the code example earlier.

> I'm sorry, but supporting the exploitation of properties of the Delphi 
> code generator is not in the scope of the FPC project.
I did not ask for that - you drew the comparison to Delphi by writing:
> My point was that Delphi sometimes also reuses temp variables.
I just pointed out that this claim is not correct.

IMO there is a potential cause for a code defect that is not obvious - 
you might go the way of the principle of least surprises and try to 
address it or argue it away for whatever reasons.

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus