Dear FPC developers,
Since I am unable to provide a comment on bug report #33912 itself, I figured I had but one option to move the discussion here. Basically, I don't follow the reasoning that led to closing the report "as designed" out of several reasons. To put the situation in a nutshell, the following (condensed) program has some very unexpected runtime behaviour but the behaviour is deemed correct as of writing and according to #33912.
type Vector = array of integer;
function DoSomething (len: longint): Vector; begin
SetLength (result,len); // whatever
end;
SetLength (result,len); // whatever
end;
var A,B: Vector;
begin
A := DoSomething(3);
// changing A here will influence B below,
// which seems ok to some as
// "managed types are not initialized when
// calling DoSomething and this is documented
// - so anything goes and stop whining".
B := DoSomething(3);
end.
B := DoSomething(3);
end.
I strongly believe that the behaviour as currently implemented is wrong and here is why.
(1) When assigning "result" to A, refcount of result needs to go down and, hence, the local var needs to be freed/invalidated. (Result goes out of scope.)
(2a) Since the compiler takes care of managing the type (hence the name "managed type"), the compiler is responsible for a minimal initialization that is in d'accord with the semantics of the language.
(2b) The syntax makes it very clear that there never is anything passed into the function, that result is a "fresh" variable living only within the scope of the function, and that A and B are very different variables. Hence result cannot have some value of a managed type returned in a previous call, which went out of scope at the time of returing to some different variable.
(2a) Since the compiler takes care of managing the type (hence the name "managed type"), the compiler is responsible for a minimal initialization that is in d'accord with the semantics of the language.
(2b) The syntax makes it very clear that there never is anything passed into the function, that result is a "fresh" variable living only within the scope of the function, and that A and B are very different variables. Hence result cannot have some value of a managed type returned in a previous call, which went out of scope at the time of returing to some different variable.
(3) The behaviour is incompatible to Delphi (tested 10.2.3 vs. Lazarus 1.8.0). Delphi shows the expected behaviour of treating A and B as distinct.
I hope this issue gets addressed, as I deem the current behaviour completely broken and also going totally against the spirit of Pascal, feeling much more like some very obscure behaviour I'd expect from some C compiler. Honestly speaking, I had started to use Lazarus/FPC couple of months ago to do some database driven app, connecting to salesforce etc. and I enjoyed the experience quite a lot. Discovering the handling of this issue, however, makes me wonder whether fpc aims to be a great Pascal compiler that does without bad surprises and very very hard to debug "documented" behaviour or not.
Thanks for your consideration,
Willibald
Willibald
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
