[fpc-devel] Const optimization is a serious bug

[Alexander Klenin]

On Thu, Jul 7, 2011 at 16:15, Chad Berchek <ad100 at vobarian.com> wrote:
> Michael wrote:
>>
>> You can always fool the compiler. The compiler trusts you and assumes
>> that what you tell her is true...
>
> Yes, of course you can always fool the compiler, it just shouldn't be
> the other way around.
Chad, this line is worthy of place among the top programmer's quotes ;-)
I think it is an excellent summary of your (and my) position.

> Alexander wrote:
>> The documentation should recommend users to never use "const
>> string" parameters
>> except cases where they can prove it to be safe.
>> Moreover, since the safety of such code may be compromised by
>> completely unrelated changes
>> (e.g. by adding {$INLINE OFF} for debugging purposes),
>> "const" modifier should not be used at all except the most
>> performance-critical code.
>
> If the compiler is actually working correctly and there is an unstated
> (perhaps even undocumented) constraint on the programmer to not modify other
> variables that use the same instance as a const parameter (even though the
> programmer cannot know that), then I fully agree with this advice.
I, like you, think it is a bug. I'd even go as far as to say that,
if it is specified somewhere, then *the specification is buggy too*.
However, given the response from FPC developers, and based an my
prior experience, I think it will be left unfixed.
Hence my alternative plan above.

> In fact, with the implicit contract theory, I propose that it would *never*
> safe to use const, because the programmer cannot control the implementation
> of the ref counted types.
Yes, I meant the same when I wrote "except the most performance-critical code",
this is to become dangerous, rarely-used and non-portable optimization
technique,
like using asm code.

Aside question -- are FPC iniling decisions platform-dependent?

> 1. To the programmer, each AnsiString and dynamic array variable is supposed
> to be unique, i.e., after doing A := B, modifying A does not affect B and
> vice versa.
AFAIK, arrays are not refcounted.

> As further support for #1, consider: With a class, you do not have to pass
> it to a procedure as var, but when you modify the instance, you modify the
> same instance as was passed to the procedure. That is how classes work.
> Having a variable point to the same object as another variable does in fact
> mean it's the same instance, the same object. That is Object Pascal's object
> model. But with strings, if you want to modify the string in a procedure and
> have that affect the argument initially passed to the procedure you *have*
> to use var. That alone should be convincing evidence that the programmer is
> always supposed to be able to assume that unique variables are unique
> instances for automatically managed strings and arrays.
This is also a good argument which I omitted before in the interests of brevity.

Put in another words, current "const string" implementation honors the
implicit contract of
"adding const in front of the string parameter cancels refcounting",
at the cost of breaking the implicit contract of "refcounted values
are indistinguishable
from simple values (except maybe in performance)".
If some specification includes both contracts, it is contradictory -- and thus,
in my opinion, buggy.
So one of the contracts should be removed -- and obviously FPC
developers think that the first one is more important, which I disagree with.

> If I may offer one other comment, I think it would be best to reserve
> comments on TStrings/TStringList and other libraries to a separate
> conversation and focus on the basic behavior of the compiler or else the
> conversation will get too confusing.
I think the discussion of the compiler behaviour is already over, and we lost.
So there is no harm in discussing fall-back strategies ;-)

-- 
Alexander S. Klenin