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.
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
