[fpc-devel] Optimization breaks check for overridden function / Is there a better way to check?
Marc Weustink
marc at dommelstein.nl
Wed Oct 22 14:05:46 CEST 2025
On 21/10/2025 08:03, Sven Barth via fpc-devel wrote:
> Sven Barth <pascaldragon at googlemail.com
> <mailto:pascaldragon at googlemail.com>> schrieb am Mo., 20. Okt. 2025, 22:14:
>
> __
> Am 18.10.2025 um 22:39 schrieb Bart via fpc-devel:
>> On Fri, Oct 17, 2025 at 9:33 PM Sven Barth via fpc-devel
>> <fpc-devel at lists.freepascal.org> <mailto:fpc-devel at lists.freepascal.org> wrote:
>>
>>> David's problem is *not* due to a corruction or a bug, but due to an
>>> optimization that FPC performs that leads to different behavior, namely
>>> changing virtual methods that are empty to EmptyMethod to reduce the
>>> number of duplicate (empty) methods in the binary.
>> Does that mena that such a check is in essence invalid?
>> IIRC then we have such a check in TCustomEdit in LCL....
> Well, the language does neither explicitly forbid nor allow it... So
> you'd have to do a more complete check that includes both the real
> base method as well as System.EmptyMethod. Maybe best move the
> general check to a separate function which gets passed both method
> pointers and then compares those as well as the base one against
> EmptyMethod.
>
>
> Sleeping about this a bit I think the solution needs to if either of two
> methods is redirected to EmptyMethod then the code must assume that the
> method was overridden, cause that's the only save assumption it can do
> (and afterall code should handle that gracefully even if it might be
> less optimal from the developer's point of view).
In the LCL case the original method is not empty so it shouldn't be a
problem there.
Marc
More information about the fpc-devel
mailing list