[fpc-devel] Const optimization is a serious bug

[Hans-Peter Diettrich]

Chad Berchek schrieb:

> Thaddy wrote:
>> It is a contract between the compiler and the programmer in which it
>> is expected that the string will not be modified inside a procedure,
>> function or method.
> 
> This is the crux of the controversy. I realized this when I was writing 
> the original post, but did not mention it explicitly because I thought 
> it would come up anyway.
> 
> The difference between a feature and a bug is the specifications. Here 
> the specifications are the documentation. I have not found any 
> documentation in either FPC or Delphi that there is some implicit 
> contract whereby the programmer promises not to modify other variables 
> which happen to refer to the same instance as a const parameter.

*Aliasing* is a common problem, not restricted to const parameters.

A subroutine may e.g. free a global object, and replace it by its 
argument. Calling this subroutine with that global object results in an 
invalid reference in the global variable.


> To me, a const parameter means that 
> you cannot modify that parameter by pointing it to something else, nor 
> (in the case of strings and dynamic arrays) alter the contents by means 
> of said parameter. (Although, you can't really "alter" the contents of 
> the instance, as copy-on-write simply creates a whole new instance.) 
> That's what it means in other languages I've used, and nothing more.

In C "const" has several meanings, comparison with other languages is 
not a good idea.

In OPL "const" means that the argument will not be altered inside the 
subroutine, so that the compiler can apply some optimizations[1]. That's 
all. The compiler *can* check for e.g. illegal writes to an const 
parameter, but there is no such *obligation*, and it's known that the 
compiler can be fooled by trickery, in any language.

[1] E.g. const record parameters can be passed by reference, instead of 
passing a copy (by value) to the subroutine. Managed types can be passed 
without refcounting and associated try-finally constructs. But there 
exists no guarantee, which compiler will apply what optimization, under 
which conditions.


I do not defend critical optimizations in an compiler. E.g. it's known 
that managed types with a RefCount of zero should not be passed as const 
parameters, *when* inside the subroutine the RefCount can be increased 
and decreased again. Here the compiler may have a chance to report an 
*possibly* inappropriate use of "const".

DoDi