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

[Martin]

On 23/06/2011 20:09, Florian Klämpfl wrote:
> Personally I don't see the need for such a check because I consider it
> as a seldom corner case but I can understand that people might be
> interested in it so if somebody implements it properly, I'am pretty sure
> it can be included.
It may bne rare, sure. But it is also one that is very hard to find. 
Because code like this may run without crash, for a long time, and by 
the time one notices it, it is hard to track. And *if* const param are 
used, it is easy to sneak in, even if the author is available of it 
(which I believe very very few people are)

>> * If it could be accepted as a feature (request), then I understand it
>> may still be open for very long, as there is no guarantee, that anyone
>> will do it.
>>
>> * Implementation
> That's what I fear :) If already the first draft looks so complicated,
> reality is typically much worse.
Very true :(


>> On top of what I already wrote on mantis. I believe my initial idea can
>> be further simplified.
>>
>> Given:  procedure Foo(const s1, s2: string);
> What about records, arrays etc. containing ref. counted types?
This case is shlighly different.

You do not have an additional  pointer to the actual char data (which is 
missing the ref count)

You have a pointer to the record (or whatever), and in there you have 
the original pointer to the char data. So the non increase of the ref 
count is correct, and needs no checks. (same as if the record was a var 
param)
True the original string (if global) may become nil or change to another 
mem location => but then so does the value in the "const record"

The check is about the ref-counting going wrong.
I already established that content change catching is a side effect, 
caused by copy on write (dynamic arrays would be able to do ref counts 
check, but would not notice content changes.

Fetching content changes, would require to either copy or checksum 
*every* const param => that is a different beast (one that I did not 
propose...)