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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel