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

[Martin Frb]

On 27/05/2026 14:27, Tomas Hajny via fpc-devel wrote:
> On 2026-05-27 13:45, Martin Frb via fpc-devel wrote:
>>
>> procedure DoFoo(s: AnsiString);
>> begin
>>    ...
>>   // paused here
>>    ...
>>    if s = ... then
>>    ...
>> end;
>> ....
>> Then that user most likely does not want the variable in the caller 
>> to be changed?
>
> Actually, I'd expect that _if_ the user wants to modify the value 
> within the debugger, he wants to have full picture of effects of the 
> modified value rather than just parcial effect which would never match 
> real case scenario when the variable has a different value. Moreover, 
> creating a copy for the modified version wouldn't change the reference 
> used in the code of DoFoo, would it? Otherwise you'd need to modify 
> not only the value, but also all parts of code in DoFoo retrieving 
> this value to point to the new copy instead, right?
>

Yes, the idea would be that telling the debugger do "set s[1] to be '?'" 
would
- check the refcount
- if 1 => then modify directly
- if 2 or greater => then
   - create a new string in the target memory
   - change the char
   - point "s" to that new string
   - decref the old string
   // all this could alternatively be a call to "uniquestring" followed 
by the modification

And that would also deal with a refcount of -1 (a VARIABLE, but pointing 
to a constant string) => which should probably ask by default.


If that is done, then the code in "DoFoo" would continue, and "s" would 
have the new value.
But the caller would still the unmodified value.

---------------------
Also I completely forgot (and currently IIRC the debugger rejects it 
entirely)

Tell the debugger to modify: MyAnsiStr := 'abc'
Then the old value needs a decref, and a new string must be created.

But if it isn't refcounted, then the old value must not be touched, just 
the new one needs to be allocated in mem, and pointed to)
// and well that may leak, if the user doesn't know what they do...

---------------------
Generally we have 2 kind of users (more, but lets simplify)

1) the beginner-like user
Someone who might not even know that FPC uses copy on write.
Someone who truly thinks that after "s1 := s2;" they have 2 completely 
unrelated values.

2) the experienced user
Someone who knows what happens under the hood, and may make use of that 
within their code. And of course during debugging.

>
>> ----------------
>> 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.
>
> OK, that indeed makes sense.

Well, and hence, back to my original question...

Any ideas what I should consider when formulating a feature request for 
additions to the DWARF standard.

And for that, the idea is to make sure that
  === The information can be added to debug info should that be needed ===

Once it can be added, we can still decide
- what we add
- how we use it

I want to avoid requesting it now, and then find that I forgot some.
E.g. I forgot that you can have properties like
   TFoo = class
      FList = array [0..9] of TPoint;
     property X2: integer read Flist[2].x;  // yes, that works
   end;
That doesn't even need function calls..
=> well that can be encoded as workaround "tag_member x2" / but then 
looses the info its a property

the DW_TAG_property support the field ".x", but not the index on the 
field var. (it supports other indices)

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

So how are ref counts used with e.g. smart pointers.
What data types will there by in smart pointers
What operations happen on smart pointers and there data