[fpc-devel] Const optimization is a serious bug

[Alexander Klenin]

On Thu, Jul 7, 2011 at 22:10,  <michael.vancanneyt at wisa.be> wrote:
> Sigh....
>
> That's what I've been saying all along. You don't even need strings for it.
> Plain records and integers will do it just as well.

Well, I am sorry, but do you all (not only Michael, I'm just
responding to the last mail in the thread)
really think I am stupid enough to not know it?
It is quite understandable that FPC developers want to defend the status quo,
but can you please do it by responding to the argument OP and I actually make?

I'll re-iterate again:
1) The reference counting is not just an optimization, it is also a
memory management technique,
an important concept which is aimed at providing "simple value"
semantics for heap-allocated structures,
and insulating the programmer from memory allocation details.
If programmer does not do anything obviously dangerous like direct
memory access,
using strings is guaranteed not to cause a whole class of memory errors,
like leaks, double-frees and access-after-free.
Current "const string" implementation breaks this guarantee for the
sake of minor optimization.
It is actually quite ridiculous: "var s: String" *is now safer* than
"const s: String",
because the former can not cause AV, but the latter can.
2) Also, there is a separate-but-related issue that Object Pascal
traditionally conflates
"const" and "reference" semantics in parameters. It would be
significantly better to have
separate "const" and "constref" attributes, but I guess it is much too late.
Nevertheless, currently there are two groups of types in FPC, "simple" types
like numerics for which "const" acts like "passing by value",
and "complex" types for which "const" acts like "passing by reference".
Note that currently "const string" *is passed by value*,
*except when the reference count equals to 1*, when it suddenly
behaves as if passed by reference.

-- 
Alexander S. Klenin