View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0026177||FPC||Documentation||public||2014-05-17 14:32||2015-06-16 19:36|
|Reporter||Maciej Izak||Assigned To||Michael Van Canneyt|
|Target Version||3.0.0||Fixed in Version||3.0.0|
|Summary||0026177: Wrong data for pointer method and "External SIGSEGV" (type helper)|
|Description||During making pointer to method for type helper method, compiler stores wrong value in data field. (value of variable instead of pointer to variable):|
TInt32Helper = record helper for Int32
procedure Foo(Sender: TObject);
procedure TInt32Helper.Foo(Sender: TObject);
i: Int32 = 10;
m := i.Foo;
// Data is equal 10 (!) but should be equal to @i
// TMethod(m).Data := @i; < workaround for bug
m(nil); // External SIGSEGV!
|Tags||No tags attached.|
|Fixed in Revision||28160|
b002.lpr (522 bytes)
For what it's worth: we are currently Delphi compatible in that regard... :/
I already have a fix available, but I don't know whether we should allow it at all as after all you can't assign record methods to method variables either...
Generics in Delphi Mode also don't work like in Delphi. Extra feature is not so bad idea :). AFAIK type helpers also exist as new type in TTypeKind so they are different by concept and incompatible with Delphi. So we should allow it :P.
Maybe it is a bit dangerous (when variable is out of scope) but for me very useful. Optionally, maybe some new modeswitch?
That it is dangerous was the first thing that occured to me as well. :)
Generics are a different example, because both implementations - that of Delphi and that of FPC - evolved in parallel and different decisions regarding its functionality were made. And IMHO implementing the helpers in that way made more sense than having yet another special class inside the System unit like Delphi did with the TClassHelperBase type...
My personal opinion is to fix it and add a big fat warning to the documentation of the helpers that this is potentially dangerous if the corresponding variable goes out of scope.
"My personal opinion is to fix it and add a big fat warning to the documentation of the helpers that this is potentially dangerous if the corresponding variable goes out of scope."
I have the same opinion :)
I've now fixed the problem and assign this issue over to Michael so that it gets documented properly.
@Michael: see comment 0026177:0075690. It applies to local variables and local/global constants. The latter because they are assigned to local temporary variables first, so that their address can be taken. Additionally it applies to fields inside a heap allocated class/record.
||Documented, so marking as fixed.|
|2014-05-17 14:32||Maciej Izak||New Issue|
|2014-05-17 14:32||Maciej Izak||File Added: b002.lpr|
|2014-06-14 15:50||Sven Barth||Note Added: 0075686|
|2014-06-14 16:02||Maciej Izak||Note Added: 0075688|
|2014-06-14 21:47||Sven Barth||Note Added: 0075690|
|2014-06-14 22:12||Maciej Izak||Note Added: 0075692|
|2014-07-05 10:57||Sven Barth||Fixed in Revision||=> 28160|
|2014-07-05 10:57||Sven Barth||Note Added: 0076078|
|2014-07-05 10:57||Sven Barth||Assigned To||=> Michael Van Canneyt|
|2014-07-05 10:57||Sven Barth||Status||new => assigned|
|2014-07-05 10:57||Sven Barth||Category||Compiler => Documentation|
|2015-01-06 14:15||Sven Barth||Relationship added||related to 0027206|
|2015-06-16 19:36||Michael Van Canneyt||Note Added: 0084512|
|2015-06-16 19:36||Michael Van Canneyt||Status||assigned => resolved|
|2015-06-16 19:36||Michael Van Canneyt||Fixed in Version||=> 3.0.1|
|2015-06-16 19:36||Michael Van Canneyt||Resolution||open => fixed|
|2015-06-16 19:36||Michael Van Canneyt||Target Version||=> 3.0.0|