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

Martin 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
> 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)

More information about the fpc-devel mailing list