[fpc-devel] Const optimization is a serious bug

[Alexander Klenin]

On Wed, Jul 6, 2011 at 03:44, Jonas Maebe <jonas.maebe at elis.ugent.be> wrote:
> 2) All such incorrect usage should be removed from LCL and FCL
> (for example: event handlers in LCL and TStrings methods in FCL).

Well, then the situation is hopeless ;-)
Note that the only reason TString/TStringList does not break too often is that
the only way to get access to an element is by calling Get, which
increments refcount
on Result, thus bypassing the bug.
If either one day "const Result" will be implemented (as suggested here:
http://delphitools.info/2010/07/28/all-hail-the-const-parameters/)
or somebody will, with good intentions, implement something like
TStrings.ForEach method,
the number of breakage modes will substantially increase.

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

Ah, of course modifying any non-local string variable should turn
optimization off too,
I just thought it goes without saying.

> 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 think the link you provided refers to interfaces, not strings.
This is the best I could find on strings, which is much more vague:
http://docwiki.embarcadero.com/RADStudio/en/Parameters_(Delphi)#Constant_Parameters

-- 
Alexander S. Klenin