On 23/06/2011 21:44, Florian Klämpfl wrote:
Am 23.06.2011 22:31, schrieb Martin:
This is about finding screwups of the refcount. The data modification
detection of strings is a side effect only.
Why is a "screwup" of the ref. count a problem? It is only a problem if
it gets 0 and the string is disposed?
Yes, that is what I meant by "screw up" (maybe not the best word, my
apology)
A change of refcount is perfectly fine
GLobVar1 := GlobVar2;
Foo(GLobVar1); // const param
While in Foo:
- you can change GLobVar2 as much as you want, no problem, perfectly
legal, breaks no rule.
- you can even change GLobVar1 (tecnically breaks the rule, but GLobVar2
keeps things ok)
- If you change both (and both in a way that memory moves), then there
is a problem.
Because then "S" in foo, is a string, that is not nil, yet points to
invalid (unallocated, or worse allocated by something else) memory. That
violates the promise that a string type is correctly managed. (Ok, the
implementor broke a promise first,, an eye for an eye, ...)
Anyway, I repeat. I do not try to detect, if the string content was
changed => that is a side effect
I try to catch issues with the refcount.
They do not happen, if the string is part of a const param record
....
begin
setlength(r.s,10);
Foo(r);
end.
... hurts as well because r is passed by value because it is small.
ok, yes, I overlooked the "passed by value" possibility.
Well, if those case can be checked too, great.
If, not, sad...
The amount of strings (and if they are in a const param by value or by
ref) should be known at compile time.
Except for dyn-array (or array of const) => dyn array, means that the
string is in as tructor that comes by ref. If the content of the dyn
array changes, then it is reflected in Foo too)
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
