View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0025990||FPC||Compiler||public||2014-04-08 17:23||2018-10-04 16:10|
|Reporter||Martok||Assigned To||Michael Van Canneyt|
|Status||resolved||Resolution||no change required|
|Summary||0025990: "as"-operator on interfaces references temporary variable|
|Description||Using the as-Operator to cast COM-Interfaces first creates a temporary variable and then copies this over to the final location. The temp variable is kept referenced until the method's cleanup section is reached.|
This causes instances to be longer lived then expected, particularly breaking (Delphi-)code when the object should be freed at some specific point, i.e. by setting a variable to nil.
Delphi does not use a temporary variable at all and rather calls IntfCast with the final target of the operation. While the example uses an assignment, the same is true for call parameters (target there is usually a reference to a register).
|Steps To Reproduce||Compile the attached program and observe its output.|
Results (FPC trunk):
RefCount should be 0...
Results (Delphi, expected):
RefCount should be 0...
|Additional Information||Original issue is in code similar to this:|
// Open File (str:IIOSeekable) and put a Decoder (dec:IIOBase64Decoder) on it
str:= TIOFileStream.Create(FileName, fmOpenRead);
dec:= TBase64Decoder.Create(str as IIOReadable);
// Clear all references, implicitly free stream and close file
// file is still open, because 'str as IIOReadable' created an invisible reference!
|Tags||No tags attached.|
|Fixed in Revision|
intf_as.dpr (670 bytes)
See also the related issues of the duplicate bug for a near infinite amount of discussion on this topic.
With that rationale, I agree on the WONTFIX.
This should however really be documented at least *somewhere* outside of this bugtracker, since this is one of those tiny things that break existing code in mysterious ways. Apart from the "file" issue everyone seems to be bringing up, there are also some cases where memory management could be weird if the tempvar indirectly keeps a large chunk of heap reserved even if nobody is using it anymore.
Something like a note in "12.8.7 Class operators" of the RefGuide or just a plain code comment on fpc_intf_as in objpas.inc would be helpful.
||I'll leave it up to Michael whether or not to document it. Documenting it with the "as" operator is the wrong place though, because as mentioned in the other bug reports this behaviour is not specific to "as" in any way.|
This is already documented, it has a section of it's own even:
|2014-04-08 17:23||Martok||New Issue|
|2014-04-08 17:23||Martok||File Added: intf_as.dpr|
|2014-04-08 17:27||Jonas Maebe||Note Added: 0074205|
|2014-04-08 17:27||Jonas Maebe||Relationship added||duplicate of 0009472|
|2014-04-08 17:27||Jonas Maebe||Status||new => resolved|
|2014-04-08 17:27||Jonas Maebe||Resolution||open => duplicate|
|2014-04-08 17:27||Jonas Maebe||Assigned To||=> Jonas Maebe|
|2014-04-08 17:52||Martok||Note Added: 0074206|
|2014-04-08 17:52||Martok||Status||resolved => feedback|
|2014-04-08 17:52||Martok||Resolution||duplicate => reopened|
|2014-04-09 00:08||Jonas Maebe||Assigned To||Jonas Maebe => Michael Van Canneyt|
|2014-04-09 00:08||Jonas Maebe||Status||feedback => assigned|
|2014-04-09 00:09||Jonas Maebe||Note Added: 0074216|
|2014-04-09 11:17||Jonas Maebe||Note Edited: 0074205||View Revisions|
|2014-05-10 17:02||Michael Van Canneyt||Note Added: 0074884|
|2014-05-10 17:02||Michael Van Canneyt||Status||assigned => resolved|
|2014-05-10 17:02||Michael Van Canneyt||Resolution||reopened => no change required|
|2018-10-04 16:10||Michael Van Canneyt||Relationship added||related to 0030409|