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

[Tomas Hajny]

On 2026-05-27 12:42, Martin Frb via fpc-devel wrote:
> On 27/05/2026 12:29, Tomas Hajny via fpc-devel wrote:
>> On 2026-05-27 12:11, Martin Frb via fpc-devel wrote:
>>> I know how refcount internally work on strings and dyn array.
>>> 
>>> I am thinking about formulating a request to the DWARF specs. So I 
>>> want to check the details, and also get information how they
>>> - will work for smart pointers,
>>> - where else they may occur?
>>> 
>>> Background, refcounts may be of interest for the debugger in at least 
>>> the following cases.
>>> - A user modifies a variable (or an indexed value) via the debugger.
>>>   ~ The debugger may additionally need info, if it should "copy on 
>>> write" / though that can be derived....
>>>   ~ The debugger could inform the user about "side effects on other 
>>> references to the value"
>>  .
>>  .
>> 
>> 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).


> 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.


> ---------------
> So for copy on write: this is about ansistrings. But the debugger must 
> know that it has a refcounted string. => and e.g for wide-types there 
> are
> - widestring (afaik not refcounted on Windows)
> - unicodestring (refcounted)

Yes, I don't want to question the necessity of understanding the 
refcounting for the debugger.


> And trying to detect that based on coincidental other criteria.... not 
> the best idea.

Correct.


  .
  .
> As for the new smart pointers, I haven't played with them yet.
> I don't expect that there will be any special behaviour on the debugger 
> side for the "modify" feature.
> 
> But....
> 
> 1) The debugger has the :ref intrinsic that currently allows the user 
> to peek at the refcount of string and dyn-array => that can be useful.
> I could imagine if you have leaks with smart pointers, then you may 
> want to trace this.

Yes, peeking the refcount may be indeed useful, that's for sure.


> 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.

Tomas