[fpc-devel] 019605: Safety check for "const s: string" (similar to Range or Overflow checks)
fpc at mfriebe.de
Thu Jun 23 23:02:20 CEST 2011
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
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
> ... 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)
More information about the fpc-devel