[fpc-devel] Const optimization is a serious bug

[Michael Van Canneyt]

On Tue, 5 Jul 2011, Jonas Maebe wrote:

>
> 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.

I agree with this proposal.

Michael.