[fpc-devel] Const optimization is a serious bug

[Jonas Maebe]

On 05 Jul 2011, at 18:27, Alexander Klenin wrote:

> 2) All such incorrect usage should be removed from LCL and FCL
> (for example: event handlers in LCL and TStrings methods in FCL).

Changing TStrings like that would break the compilation of any code that overrides its methods (since they also have to repeat/leave out const).

> Personally, I think this solution is inferior to my proposal of
> implementing the optimization
> correctly by default.

Your suggestions about the "safe" cases were wrong, as far as I can tell. As soon as a field, global variable or variable from a parent function (in case of nested functions) is changed, the parameter may also change if it is declared as const (because the field/(global) variable may contain the value that was passed in as "const" parameter). Any pointer may also alias them.

Since the behaviour of "const" for automated types is explicitly defined by Borland as not causing any changes in reference counting (see the note at the bottom of http://docwiki.embarcadero.com/RADStudio/en/Using_Reference_Counting ), I think Martin/Florian's proposal to add the ability for adding extra compiler checks is best. It's similar to how range and overflow checking are optional.


Jonas