[fpc-devel] Const optimization is a serious bug

Alexander Klenin klenin at gmail.com
Thu Jul 7 16:04:21 CEST 2011


On Thu, Jul 7, 2011 at 23:09, Martin <fpc at mfriebe.de> wrote:
> 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.

Have I not just written, in the very detailed manner, that
reference counting is a technique specifically designed to prevent this problem?
That you code CAN NOT crash, much less for non-obvious reasons,
if you use ansistring?
That this is a critical advantage of using it, as compared to, say, shortstring?
That, finally, the examples with pointers and manual memory management
are proving just the opposite of what their author wanted -- i.e.
current implementation makes AnsiString no better than PChar in terms
of safety?

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

If you look at the point (2) of the mail you responded to,
you will see that I discuss this exact issue. "Const string" is passed by value,
and it does not lead to any undefined behaviour and crashes
except this case (barring, of course, as-yet-unknown compiler bugs).

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

How so? If the bug would be fixed, any procedure with "const string" parameter
will become perfectly safe, just as with, e.g.,  "const integer".

> Given that the very same code would still be unsafe, even if ref counting
> was there, then why put ref-counting in there?
I am somewhat unsure what are you talking about here,
but if you mean the "const string" parameters, then
the statement above is incorrect.

> actually constref exists.
> but what you seem to want, which is missing: ConstButNotRef
Yes, but with less ugly syntax ;-)
Maybe "constval"?

-- 
Alexander S. Klenin



More information about the fpc-devel mailing list