> 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. > 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. There is less undefined behaviour than in C, but the one we have will bite you in the most awful ways, sometimes after years of working just fine. And we don't even have a nice formal standards document that one could grep for "undefined".
But yeah, as Jonas wrote, this _isn't_ one of these occasions. FPC uses (and reuses!) tempvars a lot more than Delphi, which causes all sorts of funny behaviours with managed types. Try returning a string or use the JavaScript-style "Foo().Bar().Baz()" method chaining pattern and you'll see what I mean. Change your function to the following, and it will do what one would expect: function DoSomething (len: longint): Vector; begin Result:= nil; SetLength (result,len); // whatever end; For managed types, as far as I can tell: - locals are initialized (even if there is a warning telling you they are not) - tempvars are initialized *once* - Result is never initialized (there is no warning telling you it is not). -- Regards, Martok Ceterum censeo b32079 esse sanandam. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel