[fpc-devel] Const optimization is a serious bug

[Alexander Klenin]

On Fri, Jul 8, 2011 at 03:35, Martin <fpc at mfriebe.de> wrote:
>>> On 07/07/2011 16:27, Alexander Klenin wrote:
>>>>
>>>> 1) That the code you posted would work quite correctly if "const
>>>> string" is fixed,
>>>>   including all the optimizations you are suggesting in the rest of
>>>> your message.
>>>
>
> A different point about this.
>
> What I understand you want is, for "const s: string" to do increase the
> ref-count. (regardless of any other issues there may or may not be).
>
> But from today's point of view, from what "const string" does today:
> What is the point in doing this.?
> Today this would be equal to simply remove the entire feature.
>
> AFAIK, today all that const string does is remove the ref count.
>
> So basically you say, because of your reasoning, no one should be able to
> use such a feature in there code?

It should do what is semantically natural for "const" -- namely,
prevent programmer from modifying the variable so declared.
Cf. "const Integer".
I understand that "const" meaning in Object Pascal has long
since lost it's meaning, but still, what it should *not* do
is breaking user programs unexpectedly.
Just step away and think about the situation:
what would you think if, say, adding C++ "const" modifier
would convert working C++ program into subtly broken one?
Note that I am not against the optimization itself --
just against the optimization which changes the meaning of the code.
Imagine, again, if the optimizer would, say, pull repeated
calculation out of the loop without checking if the variables
may be changed by some procedure called from the loop body.
Also note that, implemented properly, removal of incref/decref calls
should not depend on any const declarations, it can be performed even
for non-const strings.

-- 
Alexander S. Klenin