[fpc-devel] Const optimization is a serious bug

cobines cobines at gmail.com
Tue Jul 5 17:23:48 CEST 2011


2011/7/5  <michael.vancanneyt at wisa.be>:
> 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.

In case of ansistrings, inside the procedure you cannot also finalize
the instance that the const parameter points to. But you can modify
that instance through other variables. For example :

procedure mclass.dot(const s: string);

Here you know that you cannot modify 's'. But you may not know that
you cannot also change mclass.ftext variable, which actually 's'
points to because apparently someone called
mclass.dot(mclass.fsometext).

Maybe it is programmer error and it should be said: "never call
mclass.dot with mclass.ftext as a parameter because it may crash".
Maybe the const should have never been there in the first place. I
would say if procedure writes to some non-local strings, never add
'const' to parameter.

It is easy to start adding 'const' to every parameter but some may not
be aware of the dangers it may later bring. It should be a well
thought decision.

--
cobines



More information about the fpc-devel mailing list