[fpc-devel] Const optimization is a serious bug

[Martin]

On 09/07/2011 00:59, Max Vlasov wrote:
> On Sat, Jul 9, 2011 at 3:14 AM, Martin<fpc at mfriebe.de>  wrote:
>> function CRCConstString(constref Str: string): integer;
>> does what you describ
> Hmm, it's interesting.. Some observations:
> - constref is implemented in 2.5.1, right? Unfortunately I can not
> test it right now in 2.4.2, it refuses to recognize it, but I I want
> to test it.
> - In LCL it used only with interfaces and TGuid's, no strings or other
> structures
> - there are not much information about constrefs in Lazarus, several
> posts, the largest part of them is yours, Martin :) so you're probably
> one of the few who really understand it  :)
Well the LCL can't use it, if it's trunk only (except if IFDEFed). The 
LCL should compile with release fpc...

See: 
http://wiki.lazarus.freepascal.org/FPC_New_Features_Trunk#Constref_parameter_modifier

- See difference to normal "const" is " that it must be passed by 
reference."

- Note (same as const) it is described as: "This modifier means that the 
compiler can assume that the parameter is constant"
The "assume" means that the requirement for constant-ness goes above 
that what the compiler can enforce (that is: the compiler can enforce 
only the local var; but constant implies the value by any means of access)

With what the compiler does today (afaik) none-constantness would not 
cause any harm (yet). Unless you count it as harm (and you should) that 
future FPC may (= "is allowed to") compile your code (without any 
warning or hint) into an exe that behaves different.