[fpc-devel] Const optimization is a serious bug

[Hans-Peter Diettrich]

michael.vancanneyt at wisa.be schrieb:

> On Tue, 5 Jul 2011, Martin wrote:
> 
>> On 05/07/2011 04:02, Chad Berchek wrote:
>>>
>>> Martin wrote:
>>>> I don't think it is a bug.
>>> ...
>>>> "(const s: string)" is a declaration by the programmer, that the
>>>> variable (the string) will not be modified at all. That is neither by
>>>> the procedure called, nor by any code outside the procedure, via any
>>>> other  reference to the data. If the programmer sticks to what he
>>>> declared, then it works, if not it crashes.
>>>
>>> Is that true? I am not necessarily asserting that your statement is 
>>> false; it could well be true. However I personally have not seen it 
>>> documented so if anyone has a reference I would like to see it. As 
>>> far as I have been able to tell from the docs of Delphi and FPC, the 
>>> const declaration does NOT mean the programmer promises to not modify 
>>> the instance; it means he promises to not modify the variable, which 
>>> the compiler does indeed enforce.
>>
>> Well, I have pointed out myself,in my mail, that it probably needs 
>> more documentation. I do not know if it is documented or not.
>>
>> But it is the answer, I have gotten several times from developers in 
>> the FPC team. So for all I know it is the intended behaviour. At least 
>> intended in FPC (and apparently either intended or at least 
>> implemented in Delphi). So if there is no documentation for it, then 
>> it would appear a problem of documentation, rather than a bug in the 
>> compiler (Again all based on the statements I was given)
> 
> There is no bug.
> 
> You can always fool the compiler. The compiler trusts you and assumes that
> what you tell her is true, namely, that the called code will not modify the
> const parameter (in the case of an ansistring: a pointer). That's it. 
> Based on this she may or may not perform some optimizations.

That's my opinion as well :-)

All the rumor about hard to find errors IMO is due to the users, which 
simply should avoid "const" when their overall code then may break itself.

I'd second that "const" with object references is a bug, and should be 
removed from all library code (RTL, FCL, LCL...). But this is only a 
matter of style, not affecting compilation in any way.


[examples snipped]
> Will not produce the desired effect. The compiler cannot warn you against
> this.
> 
> I understand that with Ansistrings it's slightly more convoluted than this,
> but it's the same principle.

People with according bugs in their code should be happy with an added 
compiler option, that disables "const" parameter optimization. That's a 
quick workaround for urgent fixes, where otherwise an in-depth analysis 
of the entire application were required.

DoDi