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