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

[Martin]

On 23/06/2011 21:06, Flávio Etrusco wrote:
>>>> 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.
>> (...)
> I suppose Florian already knows that, he just meant it's basically the
> same programming/coding error. And also guess he meant "where do we
> stop"? ;-)
> Maybe just adding the option to disable the const optimization and
> letting the programmer figure out whether it fixes or not a bug is a
> good enough addition?
That assumes are reproducible error, (and implied awareness that there 
is a bug at all). Both aer none-given.

A switch to disable the feature entirely may have it's own use. But it 
is entirely different to the proposal I made.
And (with the exception of a real tiny overlap) it does not solve the 
problems that my proposal tires to solve.

that is to produce an release executable with the optimization ENABLED, 
but previously test for *certain* errors in it.

Certain !!! Not all. No check however clever can catch all errors.

This is about finding screwups of the refcount. The data modification 
detection of strings is a side effect only.

A string variable (the actual variable containing the hidden pointer) in 
pascal should have one of 2 states:
- it could be nil => that is an empty string
- It could have a memory address stored.
   In this case, the compiler makes sure, that at this memory address a 
valid string can be found.
   ( The memory is allocated, and a string with ref count 1 or greater 
is found there)

Except for fillchar, move (and such low level routines) the compiler 
offers no way, to write any code that intentionally breaks the above.
- Well yes, if you typecast to a none ref counted type, you ay somehow 
be able
- And yes, if you write to random memory, you might hit a string too, 
but that's not the problem at hand.

The only exception, where the compiler does not enforce the String<> nil 
=> means string points to valid/allocated memory, with actual string 
present... Theonly place that is not enforced is:
"const s: string" param.

And other than fillchar, I would not consider this a low level function, 
for which the user should be required of having knowledge of the 
internals on ref counted types.

Of course, if the user keeps the implicit promise, not to change that 
string, including the global var, that was passed in => then that is 
fine. Only accidents happen.
(Same as for range checks, Array x[1..3] is a promise not to access 
x[4]. Yet it can happen)



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

Of course, as soon as there are optimizations that assume the data 
wasn't changed, then there will be more issues. With and without rec 
counting.
And then we may start another discussion, looking at hose cases....

for now: ref counting.