On 04/07/2011 21:39, Chad Berchek wrote:
I've been reading over some of the recent discussion about reference
counting problems with const string parameters. I've done some
experiments and I believe that the so-called const optimization is a
serious flaw, not just a corner case of questionable legitimacy. I have
some sample code I will show which should be quite scary. Additionally,
this is a security vulnerability. It is also a quiet bug, because it may
go undetected for a long time but randomly result in unreproducible crashes.

....

I don't think it is a bug.

However It should be more prominently documented, I have found in neither of those places:
http://www.freepascal.org/docs-html/ref/refsu10.html#x33-360003.2.4
http://www.freepascal.org/docs-html/ref/refsu58.html#x135-14500011.4.4

A bug, to me is where the actual behaviour and the intended behaviour are different. However the behaviour observed is intended. (So yes, per definition a crash is only a bug, if the crash was not intended).

You can argue that this feature is not a good design decision. That is a different question. But anyway, this feature is already used, and therefore will cause lots of complains if removed.... Anyway, if you do not like the feature do not use it. ("const s : string", has no other effect but only the missing ref count => so by not using "const" in that case, you loose nothing, except that you get the refcount back)

In more detail:
"(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.

From this point of view it is no different to: "SomePointerToRecord^.RecordMember". If there is NO "if SomePointerToRecord <> nil then " to protect it, then the programmer has declared that he has otherwise taken care that the pointer is valid at the time. If the pointer is nil (or otherwise invalid), then it will crash.

Sure the pointer issue is much easier to spot. But the point is, the programmer makes a statement what is to be expected. If this expectation is not fulfilled, it is a problem of the implementation, not the feature.


For all else:
- it is probably good to draw attention to it, because the majority of people seem to be unaware. Being unaware of how are feature works, and yet using that feature, has a big potential of going wrong. (but that is not a problem of the feature, only a problem of the incorrect usage)

- Request  have been made:
A global switch to disable the optimization, for those who want not to use it.
 A debug/sanity check (like range checks) would be good


_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to