[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