[fpc-devel] Const optimization is a serious bug

[Martin]

On 07/07/2011 12:42, Alexander Klenin wrote:
>
> 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",

I do think Florians, or Mattias  example are relevant.
Let's for a moment ignore the const ansistring issue.

The 2 examples prove, that even with "const i : SomeRecord", your code 
can crash for none obvious reasons, IF you break the promise, not to 
modify the value of I, by modifying the value that you passed in.

That is:
  "const x: sometype" for any type (with the exception maybe of those , 
that are passed by value) can lead to undefined behaviour and/or 
crashes, if the promise of "const" is broken.

If the above statement can be agreed on (and the examples show this), 
then why should the "const ansi string" be a bigger issue?

Yes, the const ansi string breaks the rules that ought to be provided by 
ref-counting.
But it only breaks this ref-count promise, for code that is already 
unsave, even if ref-counting was in place.

As I have stated in my reply to Mattias, future fpc, could do all short 
of optimizations, caching the result of expressions that use only 
constants, and const param => the result of such expressions has to be 
constant too.
So even if ref-counting was in place. The code was unsafe, because it's 
behaviour is not defined, and it's results could randomly change in future.

Given that the very same code would still be unsafe, even if ref 
counting was there, then why put ref-counting in there?



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

actually constref exists.
but what you seem to want, which is missing: ConstButNotRef

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