[fpc-devel] Question: ref counts / strings, smart pointers...

[Martin Frb]

On 27/05/2026 13:03, Tomas Hajny via fpc-devel wrote:
>>>
>>> I can't imagine a reasonable scenario when a user might want to 
>>> perform a modification of a refcounted variable of the program being 
>>> debugged by using "copy on write".
>>
>> If the user assigns a new (char) value to
>>   MyAnsiString[3]
>>
>> then they might expect that.
>> After all, this is what would have happened, had there been code doing
>>   MyAnsiString[3] := '?';
>
> Yes, but there is an important difference there. If there's code 
> modifying the value, this code uses this copy from that point on. 
> However, if a user wants to modify some data in a debugger, this user 
> probably wants to do it in order of his code started to use the new 
> value instead of the original value, not because of being interested 
> in having another copy of the original data with a different value 
> (which wouldn't be used by the debugged code any longer).

I am not sure if I follow...

procedure DoFoo(s: AnsiString);
begin
    ...
   // paused here
    ...
    if s = ... then
    ...
end;

if the user tells the debugger to modify
   s[1] to be '?'

I.e. in the Lazarus IDE would open the "Evaluate/Modify" window, enter: s[1]
and set the new value to '?'.

Then that user most likely does not want the variable in the caller to 
be changed?


Of course if he had code where within a function the string was "duplicated"

   MyAnsiStrFoo := MyAnsiStrBar;
   // paused here

then both might be possible. Albeit, I find it more likely that the user 
would still wont just one string to be modified.
But if the request was to have an option to modify all strings sharing 
that memory, then ok (the user could always do ^char(MyAnsiStrFoo)[0]  
// index one less)


>> At that point, a user might not even remember that the text content 
>> of MyAnsiString may use the same memory as some other string var that 
>> they have.
>
> Yes - it's absolutely appropriate for the debugger to be aware of the 
> refcounting and warning the user if the reference counter is higher 
> than 1 and the user intends to modify the value.

In any case, there can be options for various preferences.
"power users" may indeed want to be more "memory orientated". So that 
option should probably exist.

>
>
>> 2) The debugger may need to create/destroy data, if it passes it to 
>> function calls in watches (or dec-ref results).
>> So it does need to know if there is a ref-count.
>> Once it knows the type is refcounted, it should hopefully be able to 
>> decide the correct function based on knowing what the compiler does 
>> for a given type.
>
> Function calls in watches are very tricky in any case and allowing 
> them in case of reference counted parameters sounds like a recipe for 
> problems as far as I can tell (I can imagine quite a few cases when 
> this may lead to complete change of the behaviour of the program being 
> debugged). If nothing else, the debugger should warn the users trying 
> to do that.

I don't use them myself. I got burned back in the days of Delphi 5 
(iirc). When I couldn't get the bug to trigger under the debugger, 
because I was watching
   SomeControl.Handle
(the property with getter)
And hence the debugger did create the handle, and the error was gone in 
the debugger.

But...
- there is a huge amount of people who deeply believe they can't live 
without function calls (including property getters)
- who have not yet been burned, or if they have they are not aware of it
- who will not believe that it will ever happen to them.

So well, let them have it. They have been warned...

----------------

Currently, in the few cases where FpDebug can detect an AnsiString as 
such (Dwarf-3), it can handle it in function calls (definitely as 
result, iirc as param too, including from constant in the user expression).
And FpDebug does do the correct additional calls to the rec cnt 
functions. (via the linker symbols, that usually are available)

Adding the tag will ensure FpDebug can more accurately/safely detect 
such strings.