[fpc-devel] 019605: Safety check for "const s: string" (similar to Range or Overflow checks)

[Martin]

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)