[fpc-devel] Const optimization is a serious bug

Chad Berchek ad100 at vobarian.com
Fri Jul 8 05:51:38 CEST 2011


I have just written up some very compelling arguments and then decided 
to scrap it.

I maintain that const strings, dynamic arrays, and interfaces, as 
currently implemented, are dangerous and should be considered useless in 
all but the most limited circumstances. The behavior is dependent upon 
implementation details that can change with compiler version, platform, 
optimizations enabled, etc. Unrelated changes in the code can also 
trigger bugs. Examples can be given which are extremely simple, and 
others which are extremely complex, showing how hard it can be to ever 
really trust the use of const.

The problem comes down to the specs though, or rather the lack thereof. 
As I have searched the web and read some docs at Embarcadero, things 
have only become more ambiguous. It seems that everyone repeats the same 
basic explanations but never fleshes out the subtleties. In my opinion, 
if you compared C, Java, and C++ (to a slightly lesser extent) to a 
mathematical proof, then Object Pascal in today's form would be more 
like a pile of notes and some lunchtime conversations.

Basically, I think the current behavior is bad, but whether it is a bug 
depends on the specs, which are lacking, and therefore I am no longer 
certain it is a bug. With what I have read, I no longer feel that a 
provable argument either way is possible.

I'm more interested now in a solution. The solutions I've seen so far 
have potential, but in my opinion most of them seem like they are more 
complex, would be more overhead, and produce worse performance than just 
getting rid of the const "optimization".

That being said, I can't complain because I don't have anything better 
to offer. My knowledge of FPC internals is just not enough (it is very, 
very little, actually).

However, looking at the generated assembly, I can't believe there isn't 
a more efficient way to handle the implicit try-finally. It feels to me 
like that is where the problem is. There is a lot of code and several 
function calls that go into implementing that implicit 'finally' block. 
There's got to be some way to decrement the refcount even when there are 
exceptions but without so much overhead. It would require changes to the 
exception handling mechanism though. Here my knowledge runs out.

For now, I will just agree that I believe the most practical thing to do 
is: As has already been said, have it be an optional optimization, off 
by default.

Secondly, I'm considering using var everywhere. It's ugly--very. But the 
performance of copying strings is not acceptable, and the danger of 
using const is not acceptable, except in limited well-controlled 
circumstances--but even then it's dependent on some unstated assumptions 
about the compiler implementation.

BTW, has anyone looked at my demo sufficiently that they can explain 
exactly what is happening? I do know what it's doing, but I think you 
can only really appreciate why this is dangerous if you see how subtle 
it can be. We can code very carefully, but in a large project, 
especially over time, with many people modifying it, I don't see how you 
can possibly believe using const is safe. It can sneak in so easily in 
unrelated parts of the code. That is probably what is scariest to me, 
and why I don't consider it safe no matter how careful you are. 
Personally, I feel that in the current implementation, it would be 
better for const to not even exist. I am uncertain of what I will do in 
my own Pascal coding.



More information about the fpc-devel mailing list